On Mon, 2018-09-24 at 15:43 +0200, Thorsten Kukuk wrote:
Recommends should only be used, if this adds functionality >> 80% of the users are really using it. And not like > 99,9% will never use it.
I asked last week during a talk our Labs people, if one from them did ever heard of a functionality, which got installed in every Minimalsystem due to a recommends since > 5 years. Nobody ever heard of this. But due to the result (dependencys) of this, a lot of them install with --no-recommends ...
Yes, this is indeed a major problem. --no-recommends addresses the issue in short term for one usecase, but does not take care of all the other users. Just a typical example - where I think recommends makes sense, but it breaks for users of --no-recommends: Evince, a 'document viewer', has multiple backends. Traditionally, evince was used for displaying PDF and PS files (of which PS is even debatable). A couple more backends exist: comicdoc, tiff, xps, just to name the ones I know from head. None of them is strictly required for evince - as long as you don't open any such file type with it. Based on the history of the application, we, the packagers, set the PDF and PS engines as 'supplements: evince' (reverse, as it made more sense than evince recommending other packages in this case). This works as expected, and does what we want - but only as long as nobody goes --no-recommends. This just an example for iit takes thought' to know what to do - and -- no-recommends can harm the default user experience badly. I don't have a good recipe as to solve the underlying issue though: there is nothing the review could be asked to do, as deciding about this must be done by maintainers that actually understand the package indepth, and hopefully also have some insight about the use of the package. Of course, may might ask upstream - but they will just recommend 'everything their app can do, as that's what they wrote it for'. Cheers Dominique