Hi, Adam Borowski wrote:
> What about this wording?: > > - Packages must not depend on packages with lower priority values (excluding > - build-time dependencies). In order to ensure this, the priorities of one > - or more packages may need to be adjusted. > + Packages' priorities should depend solely on functionality they directly > + bring to the user; their priority should not be modified merely because > + another package makes use of them (this can be expressed via a > + dependency). In particular, this means that C-like libraries almost never > + will have a priority above optional. > + > + On the other hand, it is allowed to _move_ such elevation to a package > + that depends on the actual implementation: for example, if we ever declare > + postgresql-client to be important, it may be elevated despite being an > + empty package that merely depends on postgresql-client-9.6. Seconded. > Obviously, this also requires changing the "extra" priority; either by > #759260 (complete removal) or at least: > > - This contains all packages that conflict with others with > - required, important, standard or optional priorities, or are only > - likely to be useful if you already know what they are or have > - specialized requirements (such as packages containing only > - detached debugging symbols). > + This priority is deprecated, but may be used to denote packages > + that are unlikely to be useful even for most users interested > + in their general field. Does this mean we're losing the requirement that two "optional" packages are not permitted to conflict with one another? In any event, that's probably better to discuss on bug#759260. Thanks, Jonathan
