Re: DO NOT REMOVE the lib packages after updates
Steve Langasek <vorlon@debian.org> writes:
> On Mon, Jul 12, 2004 at 08:17:24PM +0200, Goswin von Brederlow wrote:
>> Josselin Mouette <joss@debian.org> writes:
>
>> > On lun, 2004-07-12 at 18:31 +0200, Eduard Bloch wrote:
>> >> > Except in some rare cases (e.g. libpng), that's a very bad idea.
>> >>
>> >> And why? I just showed that it works.
>> >
>> > And that it bloats the archive, is a pain to maintain, not speaking of
>> > the security updates.
>> > --
>> > .''`. Josselin Mouette /\./\
>> > : :' : josselin.mouette@ens-lyon.org
>> > `. `' joss@debian.org
>> > `- Debian GNU/Linux -- The power of freedom
>
>> It only bloats the archive during the transitional period. After all
>> packages depending on the lib have been recompiled the old package can
>> be removed.
>
>> The longer that period lasts the more important having 2 packages is
>> since otherwise you would have broken packages for the same amount of
>> time.
>
> The counterargument is that, without the pressure of RC bugs, the
> transitional period will last longer. I think we would need to be able to
> file "please recompile" bugs at RC severity to avoid compromising our
> ability to get the libs section in shape for a release.
There are two cases:
1. The source needs just recompiling without any change.
So why not just do it. Every DD can upload a binary-only recompile
NMU. Granted its work getting a package compiled on all archs but you
can do it. Or you can do a source NMU (after giving the maintainer
enough time) with just a new changelog entry so buildds comile it.
2. The source needs porting to the new lib.
This should only happen for API changes in which case there will be
lots of changes for the sources and the packages should probably
coexist for a longer time.
The old package should be marked for removal (but not yet removed) and
personally I would think RC bugs against its reverse depends are then
justified. Reason: 'Depends/Build-Depends on package marked for
removal.' Kind of preemptive will be uninstallable/buildable
bugreports. I hope every maintainer prefers getting such a bug
preemptive (so he has time enough to fix it) instead of getting the
real thing.
>> As for security updates that's pretty easy. Remove the old lib. You
>> wouldn't loose anything compared to removing it directly but you keep
>> packages working as long as there is no security bug.
>
> This does nobody any good once we have a stable release that includes the
> parallel package for the old library.
Transitions should better be completed before a release. If it gets
into stable its hardly a short term coexistance anymore. I fully agree
that you should remove old transitional packages from testing before
release along with all its reverse depends. Besides it being a bad idea
you also get the problem of providing source for the old and new package.
I also wouldn't like to see sudden soname changes right before a
release without good reason. Too many new bugs (usually).
> And even "just remove the library" means piling more responsibility on our
> straining security infrastructure that doesn't need to be there.
I agree with you that it shouldn't enter stable and then the security
team is left unburdened.
> --
> Steve Langasek
> postmodern programmer
MfG
Goswin
PS: The last big lib changes rush (gnome 2.6) at first didn't keep old
libs and caused the new sources to be actually unbuildable. Some libs
had to be reuploaded with old and new versions to get the the rest
compiled at all. Think about that.
Reply to: