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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
