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
Reply to: