Bug#707219: release.debian.org: check co-installability of standard
On Tue, Jan 12, 2016 at 10:38:05 +0100, Raphael Hertzog wrote: > Hi, > > On Wed, 08 May 2013, Julien Cristau wrote: > > britney doesn't currently check that required+important+standard > > packages are all co-installable. It might be a good idea to add a > > faux-package to check that? > > This check would probably have avoided #810785 where ifupdown 0.8.6 > entered testing with a Breaks against the version of systemd which > is in testing. > > Thus it would be nice to implement this, even with a hardcoded list > for a start, it's better than nothing. > > Having debootstrap broken is a big issue for anyone working with testing. > Not for "anyone", no. Please don't pretend this is a bigger problem than it really is. Annoying? Sure. But not the end of the world, there are easy workaround for anyone who can't deal with a few days' breakage. Cheers, Julien
Bug#707219: release.debian.org: check co-installability of standard
Hi, On Wed, 08 May 2013, Julien Cristau wrote: > britney doesn't currently check that required+important+standard > packages are all co-installable. It might be a good idea to add a > faux-package to check that? This check would probably have avoided #810785 where ifupdown 0.8.6 entered testing with a Breaks against the version of systemd which is in testing. Thus it would be nice to implement this, even with a hardcoded list for a start, it's better than nothing. Having debootstrap broken is a big issue for anyone working with testing. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#707219: release.debian.org: check co-installability of standard
On Sat, May 11, 2013 at 15:28:44 +0200, Niels Thykier wrote: If we do actually obtain this state where we can say that = standard packages are always (co)installable in testing, it will open up some new possible ways of optimizing Britney. E.g. we would be able to answer is_coinstallable(pkg1, pkg2) with yes in O(1) for packages with priority = standard (and maybe for others in O(1)). I think making this assumption in britney's code would be a bad idea, fwiw. A force-hint would let you break it, if nothing else, and it'd be better if she noticed. Cheers, Julien signature.asc Description: Digital signature
Bug#707219: release.debian.org: check co-installability of standard
On 2013-05-12 11:48, Julien Cristau wrote: On Sat, May 11, 2013 at 15:28:44 +0200, Niels Thykier wrote: If we do actually obtain this state where we can say that = standard packages are always (co)installable in testing, it will open up some new possible ways of optimizing Britney. E.g. we would be able to answer is_coinstallable(pkg1, pkg2) with yes in O(1) for packages with priority = standard (and maybe for others in O(1)). I think making this assumption in britney's code would be a bad idea, fwiw. A force-hint would let you break it, if nothing else, and it'd be better if she noticed. Cheers, Julien I wouldn't worry about that. Checking that the assumption is valid is a lot faster than checking co-installability in general[1]. I.e. we can verify the assumption holds before (ab)using it. ~Niels [1] Verification would probably be at the order of O(|V| * |E|). A full co-installability check is definitely worse than that. -- 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/518f6672.3070...@thykier.net
Bug#707219: release.debian.org: check co-installability of standard
On Wed, 2013-05-08 at 22:52 +0200, Niels Thykier wrote: I like the idea. I am thinking we could (at excuse time) reject packages with a breaks/conflicts on priority:optional or higher (unless the package is priority:extra). Is the optional / extra split actually well enough defined these days that must not depend on a package with a lower priority works as a means for blocking migration? If we were to adopt such an approach, it would need some refinement. I don't think that a versioned Breaks on a package older than the version in testing should block migration, for example (it might cause upgrade path issues, but that's another bundle of fun). There will also be cases (such as the recent less / man-db issue) where the migration would work if both packages migrated in the same run; at worst that particular case probably degrades to the breaking package not being able to migrate until the run after the new version of the broken package though. 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/1368276141.7990.25.ca...@jacala.jungle.funky-badger.org
Bug#707219: release.debian.org: check co-installability of standard
On 2013-05-11 14:42, Adam D. Barratt wrote: On Wed, 2013-05-08 at 22:52 +0200, Niels Thykier wrote: I like the idea. I am thinking we could (at excuse time) reject packages with a breaks/conflicts on priority:optional or higher (unless the package is priority:extra). Is the optional / extra split actually well enough defined these days that must not depend on a package with a lower priority works as a means for blocking migration? Not sure what the general state is irt. optional vs. extra, but we could add/re-enable it later if it is a problem. If we were to adopt such an approach, it would need some refinement. I don't think that a versioned Breaks on a package older than the version in testing should block migration, for example (it might cause upgrade path issues, but that's another bundle of fun). Indeed. There will also be cases (such as the recent less / man-db issue) where the migration would work if both packages migrated in the same run; at worst that particular case probably degrades to the breaking package not being able to migrate until the run after the new version of the broken package though. Indeed, I also wanted the implementation to handle this case. In particular, in these cases we should probably have it in the packages in together. Regards, Adam If we do actually obtain this state where we can say that = standard packages are always (co)installable in testing, it will open up some new possible ways of optimizing Britney. E.g. we would be able to answer is_coinstallable(pkg1, pkg2) with yes in O(1) for packages with priority = standard (and maybe for others in O(1)). Besides that, enforcing the priorities would also avoid the occasional mismatching priority bugs for packages in stable. ~Niels -- 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/518e478c.2090...@thykier.net
Bug#707219: release.debian.org: check co-installability of standard
Package: release.debian.org Severity: wishlist User: release.debian@packages.debian.org Usertags: britney Heya, britney doesn't currently check that required+important+standard packages are all co-installable. It might be a good idea to add a faux-package to check that? Cheers, Julien signature.asc Description: Digital signature
Bug#707219: release.debian.org: check co-installability of standard
On 2013-05-08 11:59, Julien Cristau wrote:
Package: release.debian.org
Severity: wishlist
User: release.debian@packages.debian.org
Usertags: britney
Heya,
britney doesn't currently check that required+important+standard
packages are all co-installable. It might be a good idea to add a
faux-package to check that?
Cheers,
Julien
I like the idea. I am thinking we could (at excuse time) reject
packages with a breaks/conflicts on priority:optional or higher
(unless the package is priority:extra). This would mean we don't have
to maintain the faux-package and Britney would just DTRT on her own.
Though it is probably not a flawless solution unless we at least also
check the dependencies have the right priority at excuse time as well[1].
~Niels
[1] Else out-of-date priorities could cause the effective set of
packages in {required,imported,standard} to break co-installability.
--
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/518abb13.8060...@thykier.net
