Hello, On Feb 21 13:39 Robert Kaiser wrote (excerpt):
Stuff that is required for a system to be functional should absolutely be in *requires* IMHO.
Yes and no depending on what is meant with "functional". In general RPM requirements should be only used for essential stuff i.e. for stuff without a software could not at all work (e.g. RPM requirements for libraries where binary programs are linked with or the needed runtime environment for interpreted programs and things like that). For anything else RPM recommends should be used. RPM requirements are hard dependencies that cannot be skipped by the user (without having unresolved dependencies in his system). In short: Keep RPM 'Requires' as small as possible - i.e. only what is mandatory to make it work at all - and specify all what is not really essential as RPM 'Recommends'. For an example you may have a look at https://bugzilla.opensuse.org/show_bug.cgi?id=776080#c39 Therefore it is a missing RPM requirement when stuff is missing without a software can not at all work. But it is no missing RPM requirement when stuff is not installed that is needed to normally use the system, i.e. to make the system "functional" for a specific use-case. For example when zypper is not installed it is no missing RPM requirement because there are use-cases where zypper is not essentially needed on a system. What RPM packages need to be installed to normally use the system for a particular use-case cannot be defined in RPM requirements of normal software packages because then there would be ony one singe use-case: The one that is defined by the hardcoded RPM requirements in the normal software packages. Therefore what RPM packages need to be installed to normally use the system for a particular use-case must be defined "outside" of the normal software packages. Things that should be installed to normally use the system are specified via so called "patterns" which exist for different use-cases. Each pattern is basically a list of RPM packages that need to be installed to normally use the system for the particular pattern's use-case. Technically - as far as I know - patterns are implemented as special RPM packages that do not contain files to be installed but only RPM requirements and recommends for other RPM packages where those other RPM packages can be other patterns or normal RPM software packages. Accordingly this means when things are missing or superfluous to normally use the system for a particular use-case, the missing things would need to be added to a matching pattern or the superfluous things would need to be removed from the matching pattern(s). In the end the problem is to define the patterns well. To define the patterns well it is a precondition that there are no superfluous RPM requirements in normal packages. I think this leads to the question to what extent RPM recommends in normal packages make sense because RPM recommends in normal packages behave in practice same as RPM requirements in normal packages when all that recommended stuff is installable. I think RPM recommends in normal packages result that there can be only one "recommended" use-case: The one that is defined by the hardcoded RPM recommends in the normal software packages. Accordingly it seems also recommended stuff cannot be defined via RPM recommends of normal software packages but recommended stuff must also be defined via patterns. If I am right this may in the end even lead to the finding that only RPM requirements are needed and RPM recommends are actually superfluous because when both requirements and recommends need to be defined via patterns, a pattern only needs RPM requirements because one can have differnt patterns for a minimal set of packages for a use-case and a recommended set of packages for the same use-case and a full bown-up set of packages for the same use-case. I think RPM recommends are perhaps only useful for "graceful degradation" when stuff that is needed by a pattern is not installable. But I wonder if such "graceful degradation" really helps. Assume there is the 'foo' use-case with the matching patterns 'foo-minimal', 'foo-recommended' and 'foo-full'. Now imagine a user wants to have 'foo-recommended' installed but some of that stuff is not installable. If there were only RPM requirements in the patterns, the 'foo-recommended' pattern cannot be installed (or it fails to install the 'foo-recommended' pattern). This results a clear message to the user that with his current package repositories he just cannot get 'foo-recommended' correctly installed. In contrast if there are RPM recommends in the 'foo-recommended' pattern, it may look to the user as if he got 'foo-recommended' installed but later the user may find out the hard way that actually some recommended packages of the 'foo-recommended' pattern were (perhaps even silently) not installed. Is my above reasoning at least basically right or do I perhaps misunderstand something here? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org