Kevin Kofler wrote: > Hans de Goede <j.w.r.degoede@...> writes: >> 1) When a package update would cause an soname change then a compat >> package with the old libraries must be provided for all release repos, >> that is for all repos except devel. > > IMHO this is ridiculous. Even Core doesn't follow such a strict policy. This is > going to hinder critical security upgrades for packages such as SeaMonkey, and > also leave rapidly-changing libraries (which are the ones needing version > upgrades the most!) stale at old versions (and you can quickly end up with > dozens of compat packages for the same library if it is _really_ rapidly > changing). I think the current policy of simply getting packages rebuilt if a > soname changes (which is also what is done when Core upgrades a soname) works > well. > Did you even bother to read the entire proposal? Thats _exactly_ what the quick and dirty compat rule is for and without these rules we have things like a directfb update causing yum update to fail for days in a row, locking out most users of those o so vital security updates you're defending over here! Also if such a security update is indeed done without any rule on howto properly handle / coordinate the soname change yum update will simply refuse to update, so the fix won't reach its intended audience (the end users). I do agree with you that "you can quickly end up with dozens of compat packages for the same library if it is _really_ rapidly changing" although that can easily be solved simply by: 1) asking maintainers to rebuild against the newest release 2) when releasing a new compat package remove all of the older compat package under the condition that no other package requires that older compat packages. And have you ever considered that if upstream changes the soname every few days that upstream then is seriously borked and you thus have a much bigger problem? Regards, Hans -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
