Hi, For recommends, since TC is voted for "We advise the policy maintainers to consider how to clarify ...", here is a reference information for drafting such clarification clause.
Whereas the original concern of this bug was the use of recommends by metapackage, the underlining issue is broad and unrestricted definition of use of recommends, I think. > The Recommends field should list packages that would be found together > with this one in all but unusual installations. The word "together" has no sense of dependency direction. Related problem is library recommending particular binary as discussed recently in debian-devel: Subject: Re: use of Recommends by vlc to force users to use pipewire From: Jonas Smedegaard <jo...@jones.dk> To: debian-de...@lists.debian.org Date: Thu, 26 May 2022 17:59:38 +0200 (05/27/2022 12:59:38 AM) Message-Id: <165358077835.2132435.4699236542149578...@auryn.jones.dk> Here Jonas has a interesting view point of "direction". Let me quote: > Package relations are directional: Applications need libraries, but > libraries rarely need applications. > > libpipewire-0.3-0 should not recommend pipewire, because the library > cannot know if reverse dependencies needs it strongly or weakly. I know suggest/enhance definition has view point on direction. I don't see it in recommends. In the related posts, issue of recommending xdg-desktop-portal end up pulling in WebKitGTK is discussed. This aspect is something to be accounted. The use of ored recommends in that discussion threads by Vincent is also needs attention. > AFAIK, this kind of issue is normally solved with on ORed Recommends > (when a virtual package is not defined for that). For instance, > libaspell15 has > > Recommends: aspell-en | aspell-dictionary | aspell6a-dictionary > > So, if the user already chose a solution, it won't be overridden > by the default. > > Here, this could be > > Recommends: pipewire | pulseaudio > > but IMHO, it is not up to libraries to do such Recommends, but > to audio applications or desktop environments, or something > done automatically at installation time where the user chooses > which kind of installation he wants? But isn't a sound system > already installed by default with a typical installation of a > desktop machine? I think another direction question is data package to utility tool, and documentation package to its utility. Also considering normal use cases, circular dependency created by depends+recommends combination needs to be addressed to avoid situation like: https://bugs.debian.org/655483 Technical solution by aptitude is one thing but having sane policy to avoid creating such cases as much as possible is desirable thing. Having some thing of "direction" in recommends usage definition may help. Just a thought. Regards, Osamu PS: BCCed people quoted.
