Bug#681419: Alternative dependencies on non-free packages in main
Don Armstrong <don@debian.org> writes:
> I personally believe this is acceptable, but only with the following
> caveat: under no circumstances should foo-nonfree be automatically
> pulled in. [That is, there cannot be a conflicts or similar arrangement
> where the package resolver seeks to pull in foo-nonfree to solve the
> problem.]
>
> For example, if foo conflicted with baz, but foo-nonfree did not and baz
> was installed, foo-nonfree could be installed in preference to foo
> without the user specifically asking for foo-nonfree.
It seems like it would be difficult for the person adding the alternative
dependency to know whether this is the case, and it could change later
without any changes to the package that has the dependency. That means
that I'm not sure how I would capture the above in guidance to the
packager in a document like Debian Policy.
More broadly, if it's there as an alternative dependency, then I think
it's hard to know whether the dependency evaluation scheme might choose to
pull it in for other, less obvious reasons. For example, the non-free
version might have fewer dependencies, or the free version may have
dependencies that have transient installability issues. I don't see how
to guarantee the behavior that you want.
I had previously assumed that we weren't worrying too much about issues
like that because the end-user had to have explicitly enabled the non-free
repository to have any of the non-free packages become candidates, and
that (having enabled that repository) they were requesting the best
possible dependency resolution including the non-free repository. (This
is, to a large extent, exactly the point of contention in the Policy bugs
that I'm escalating.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: