On Sat, 01 Jul 2006 17:54:07 +0200, Hans de Goede wrote: > I think you are trying to make this failproof in a totally over the top > way. Totally over the top is when SONAME changes or API changes are introduced into release branches _without_ prior communication or without clear benefit. > The end result being that nobody will do a soname bump in the > non-devel branch possible keeping nice packages out non devel branches > because they need a newer version and/or keeping bugs in the non-devel > branch because releasing the bugfix version would require the maintainer > todo some kinda big and long ceremonial dance. On the contrary, packagers switching BR from foo-devel to compat-foo-devel, not getting any bug fixes, then sticking to compat-foo-devel, with the result that there are multiple instances of "foo" in a release branch, some with -devel packages, others not. No fun! > I wrote this with cases like directfb in mind where upstream changes the > soname every! release. This is an education problem. Contact upstream and lobby for a smarter release scheme. I've seen library authors who just didn't care much about how their version info ended up in the soname in an inappropriate/unexpected way. Also, a single ugly case does not justify rushing things and coming up with a general policy which opens up the flood-gates for many other compat-libfooX packages to enter a distribution. Much of this is about _release branches_ of the distribution. And I really would like to see _who_ does the needed investigation as whether and how a new library breakes API/ABI and so on _before_ publishing rushed compat-foo packages. > The whole idea behind my policy proposal was to > have a sane and reasonably* safe policy, while at the same timing not > making it nearly impossible for maintainers to actually do an soname change. IMO, many maintainers don't do any ABI/API checks at all when they release upgrades. Similarly, they don't compare the feature set of released packages with the packages to be released. > *100% safe does not exist, get that stupid notion of 100% safe out of > your head please It's not stupid. It's a different point of view. > As I also wrote a API change which causes non trivial to fix build > errors, makes it mandatory to add a -devel sub package to the compat > package, so in the security problem case the fixed package can build > against this -compat-devel package. Which a) must co-exist with the new -devel package, must co-exist with further compat -devel packages (because you don't limit the number of compat packages), and b) can be a non-trivial thing to create (e.g. think of moving headers, renaming helper scripts, libfoo.so points to most recent SONAME). > But I've learned from your and other reactions that there is appearantly > no support on the list for a balanced soname policy. With the end > result being that there probably isn't going to be any policy at all. > > I must say I'm disappointed in the lack of the ability to see the > balance of things here on the list. > > Because of this will probably be my last post in this thread. For some topics it needs quite some endurance before a satisfactory solution is developed. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
