On 09/09/2013 17:03, Adam D. Barratt wrote:
On 2013-09-09 15:44, Jérôme Vouillon wrote:
It seems Britney will happily remove from testing any binary package
taken over in sid by another source package when its initial source
package is
removed or updated, instead of waiting for the new version of the
package to be
ready. I'm wondering whether this is an expected behavior of Britney.
So far as I can see, you're misdiagnosing the cause(s) of the issues
you're seeing. It has nothing to do with whether the binary packages
have been "taken over", simply whether they exist in the version of
the package migrating.
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?
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.
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. And I don't really see what the maintainer of
the packages should do to avoid that.
Regards,
Jérôme
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
