[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: soname change policy proposal

Jeremy Katz wrote:
> On Tue, 2006-06-27 at 13:59 +0200, Hans de Goede wrote:
>> please reread the little howto I wrote, then you'll that the package
>> is effectivly unchanged, just renamed and stripped of its -develo
>> subpackage. I just realized that if its a mixed lib and binary package
>> it should actually be stripped of everything except the libs and %doc.
>> So maybe the howto needs some rewording, but as said the idea is that
>> this isn't a _new_ package is just a rename of an exisiting one! 
> ... in that case, it should be quick and easy for the review to
> happen :-)
> Jeremy

Its unnescesarry pain for the maintainer and an unnescesarry burden on
the Review process which is already overloaded as is.

Also see what 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
> 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.

So he thinks that even mandating a compat package is a bad idea, I'm
tryign to find some middle ground here.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]