Bug#722262: Packages removed from testing when taken over by another source in sid
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. 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. Likewise, libcolord-gtk-dev and libcolord-gtk1 were removing from testing when the source package colord was updated on July 6; The source package was updated to remove those binary packages. If the old packages have no dependencies in testing and are no longer built from any package in testing, then keeping them in testing would be wrong (as the source used to build them would no longer be in testing). a new version of these packages were put back in testing the next day together with their new source package colord-gtk. Finally, ulogd and other packages from the source package ulogd were removed from testing on July 7, while transitional dummy packages of the same names remained in sid until July 15 together with the new source package ulogd2. Again, the packages were removed from unstable on the date quoted, and had no reverse dependencies in testing, so there was nothing holding them in testing. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/81076852796b7be6e882ac36bad6b...@mail.adsl.funky-badger.org
Bug#722262: Packages removed from testing when taken over by another source in sid
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: britney 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. 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. Likewise, libcolord-gtk-dev and libcolord-gtk1 were removing from testing when the source package colord was updated on July 6; a new version of these packages were put back in testing the next day together with their new source package colord-gtk. Finally, ulogd and other packages from the source package ulogd were removed from testing on July 7, while transitional dummy packages of the same names remained in sid until July 15 together with the new source package ulogd2. -- Jérôme Vouillon -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130909144402.25025.21853.report...@keithp.irill.org
Bug#722262: Packages removed from testing when taken over by another source in sid
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-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522e402e.20...@pps.univ-paris-diderot.fr
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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1378788626.3229.26.ca...@jacala.jungle.funky-badger.org
Bug#722262: Packages removed from testing when taken over by another source in sid
On 09/09/2013 11:39 PM, 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: 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. A way to avoid that is to first start depending on the binary package one will take over, have that migrated to testing, before really taking it over AFAICS. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522ea74f.8010...@debian.org
