Bug#722262: Packages removed from testing when taken over by another source in sid
On Mon, 2013-09-09 at 23:39 +0200, Jérôme Vouillon wrote:
> On 09/09/2013 17:03, Adam D. Barratt wrote:
> > On 2013-09-09 15:44, Jérôme Vouillon wrote:
> Thanks for your comments! I understand what Britney is doing, but I
> don't really understand the rational for that. I'm wondering when it is
> useful to automatically remove a binary package from testing while a new
> version of this package is present in sid. Shouldn't one take this new
> version of the package in sid as a hint that the package is still useful
> in testing?
What's the alternative?
This is a serious question. So far as I can see, the choices are either:
1) to try and work out which source package(s) have/has superseded the
old source and make the removal conditional on the migration of the
other package(s).
2) to not remove the binary packages from testing when removing the
source package if the binaries are still built from some other package
in unstable.
2) is definitely wrong (as we'd no longer have the source used to build
the packages in testing) and in most cases 1) is probably more of a pain
than the current situation; I'm also not sure (but could be missing
something pre-coffee) that there aren't situations where it's actually
the wrong thing to do (e.g. when some of the binaries have been
intentionally dropped from a source and the new package isn't expected
to migrate).
It also depends on how you define "useful". This situation can only
apply to packages that have no reverse dependencies in testing,
otherwise the removal attempt would have failed.
> >> For instance, package proftpd-mod-geoip was removed from testing
> >> together with its source package on July 1, while the new version of
> >> the package build from
> >> the source package proftpd-dfsg is still stuck in sid.
> >
> > This was because the source package was removed from unstable on the
> > same day. When a source package is removed from unstable, britney will
> > automatically try and remove it from testing as well; if there are no
> > reverse-dependencies keeping it in testing then that will succeed.
>
> Here is the whole picture, as far as I understand. The ProFTPD source
> code now includes the GeoIP module (which used to be distributed
> separately). So, the new version of proftpd-dfsg uploaded to sid now
> produces a binary package proftpd-mod-geoip. Once this binary package
> was built in sid, the source package proftpd-mod-geoip was automatically
> removed by auto-cruft (obsolete source package). Then, since the source
> package was removed from sid, Britney proceeded immediately to remove
> the source and binary packages proftpd-mod-geoip from testing.
> Meanwhile, the new binaries were still not old enough to move to testing
> (and was further delayed due to RC bugs and a new upload). I'm not sure
> this is what the maintainer of proftpd-mod-geoip intended.
It may well not be. As I mentioned before though, this can only happen
if nothing outside of the proftpd-mod-geoip source package depends on
the binary packages, otherwise the removal attempt would have failed.
> About the same thing happened with ulogd/ulogd2.
>
> So, basically, when the binary packages produced by some source package
> are all taken over by another package, these binaries will usually be
> automatically removed from testing some time before the new version of
> the binaries are ready.
Again, only if they have no reverse dependencies in the archive.
> And I don't really see what the maintainer of
> the packages should do to avoid that.
Is this actually causing any practical problems, rather than "seeming
the wrong thing to do"? fwiw, the maintainer could ask us to block the
removal temporarily, although either they or we would then have to
remember to disable the block once the new source was ready to migrate.
Regards,
Adam
Reply to: