Don Armstrong <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
