soname change policy proposal

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.

        Kevin Kofler

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

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-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list