
Hello, On 2022-02-16 15:48, Jan Engelhardt wrote:
On Wednesday 2022-02-16 13:51, Johannes Meixner wrote:
only an addedum to emphasize a specific point:
On 2022-02-16 13:23, Dominique Leuenberger / DimStar wrote:
* Pkg X needs A to run => Requires ... The 'Requires' case is pretty obvious
I think the 'Requires' case is only clear when it is written more to the point: Pkg X cannot run without A => X Requires A
My point is that "Pkg X needs A to run" could be misunderstood as "normally users of X need A to run X for usual use cases". But actually X may run even without A (for specific use cases like some minimal use cases in special unusual environments).
Bottom line: What is not strictly required schould not be specified as 'Requires' but only as 'Recommends'.
The thing is, evince without any document plugins is like a kernel without filesystem support. You can run it technically speaking, but it's dead weight at that point for the 99th percentile.
as far as I see you proved my point. It does not belong to the evince RPM to enforce the user to have some specific plugin installed. If evince without any document plugins is not useful then the evince RPM may recommend some usually needed plugins (i.e. usually needed by the user but not technically required). But actually what is usually needed by the user should be better specified via patterns. As far as I know patterns are basically empty RPMs that only have dependencies. So I think patterns can require and recommend things. For example a "desktop" pattern may even require evince (if that desktop could not work normally without it) and also require some standard evince document plugins which are considered to be mandatory for "desktop" usage. A user who wants his explicit specific set of RPMs could remove such a "desktop" pattern (provided that pattern is not required but only recommended) and install evince with plugins as he specifically wants. A theoretical example: Assume there are two desktop environments. "DesktopA" uses "reader1" for "this" documents and "reader2" for "that" documents but "DesktopB" uses "reader1" for "that" documents and "reader2" for "this" documents. It is impossible to specify this two use cases in the "reader1" and "reader2" RPMs because both contradict (recommends vs. requires don't help here). So neither "reader1" nor "reader2" should specify its use case (because one RPM spec file can only specify one "hardcoded" use case). Instead there should be "DesktopA" and "DesktopB" patterns so that each use case can be specified separatedly and the user has the freedom of choice, cf. "freedom 0" at https://www.gnu.org/philosophy/free-sw.html when "the program" is a whole Linux distribution. By the way: Users who globally refuse recommeded packages get what they ask for: They get full control over all installed RPMs only limited by what is actually mandatory which means they are fully responsible for all their installed RPMs - of course. In the end it is about if there is "freedom and final power at the user" or "final power at the Linux distributor". Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev