Stefan Seyfried wrote:

On 20.02.2018 09:44, Ludwig Nussel wrote:

...

With this second generation of the package list generator I started from scratch with Leap 15. So what you see now there is basically what a default install of KDE resp GNOME has, some packages tested by openQA (that should actually be listed in some pattern instead) plus packages for hardware support (ie packages with modaliases).

...

So for the case Seife found (fluid-soundfonts) the question is: Do we need that in a default install or not?

I don't :-)

...

IMO if it's needed it should be on the DVD. If not, a network install shouldn't pull it in either. IOW please someone fix the packages that recommend such candidates.

<package name="fluid-soundfont-gm"/> <!-- reason: gnome:suggested:patterns-gnome-gnome:timidity --> <package name="fluid-soundfont-gs"/> <!-- reason: gnome:suggested:patterns-gnome-gnome:timidity --> <package name="timidity"/> <!-- reason: gnome:suggested:patterns-gnome-gnome:timidity -->

Fun fact: timidity is not mentioned anywhere in https://build.opensuse.org/package/view_file/openSUSE:Leap:15.0/patterns-gno...

So what pulls it in?

...

As a side note the "minimal" server installation also exploded⁴. Help appreciated to take a close look at pattern and package dependencies to optimize default installations. That will also help for having sensible DVD content.

Just "requires" and "recommends" without hints are not going to solve this. We either install too little (basically "--no-recommends") or too much. IMO the solver needs a hint, maybe "recommended also for smaller sytems" or "recommended, but only when you really want a seriously fat installation". Of course I have no idea how to implement that.

And we won't get that for Leap 15 anymore. So we have to live with the technology we have.

Note that I doubt the usefulness of the "network installation should be identical in result to the ISO installation" mantra Either we will strip usefull recommends from packages, or we'll end up with everything and the kitchen sink on DVD (and will not be able to fit a single desktop into 4.2GiB)

Before we get to the point to strip useful Recommends we first have to get rid of the not so useful ones. Looks like there are plenty. The ability to play MIDI files is probably not really relevant these days so support for it can be made entirely optional instead of "recommended". cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Michal, On 20.02.2018 10:54, Michal Kubecek wrote:

On Tuesday, 20 February 2018 10:17 Stefan Seyfried wrote:

...

I'm personally not too concerned about the recommends (I have hard-coded "--no-recommends" in my zypper-typing-fingers anyway)

"solver.onlyRequires = true" in /etc/zypp/zypp.conf is one of the first things I set on every openSUSE or SLE right after the installation

True. However, if you do this *before* the installation, you get a very small (and often dysfunctional) system. It would certainly save a lot of space on the DVD. And make it mostly harm^Wuseless. OT anecdote: I learned this the hard way, when I built our server images in OBS/KIWI with "patternType='onlyRequired'". The sublte dysfunctionalities not only made me many "friends" at L3 support but also drove me almost crazy, until I finally switched back to "plusRecommends" -- Stefan Seyfried Ceterum censeo fluid-soundfont esse delendam (from the Leap 15 DVD :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Ludwig, On 20.02.2018 13:11, Ludwig Nussel wrote:

Any concrete issues identified? I wouldn't hold my breath for the desktops but I'd assume that installing without recommends should at least work for the server installation. If that's not the case right now let's try to fix it for Leap 15.0.

SLES12-SP1 or SP2 (not sure anymore) basically just patterns-sles-base plus a handful of packages in the kiwi file (full provisioning and configuration would be done at first boot via salt/chef/ ansible/whatever) It was a strange issue basically not being able to use /etc/security/limits.conf. The settings/limits just did not get applied. Some library, pam module, whatever missing. System worked fine, but everything had default ulimits. 1024 file handles. Such stuff, which makes big servers fail after a few weeks. Our usual way of configuring this via limits.conf did just not work. I looked hard, for a long time, but was not able to fix it afterwards. Finally I built the images with plusRecommends (now 600MB instead of 450MB), reinstalled and lived happily ever after. Ever since I reject kiwi files without "plusRecommends" by default in my OBS instance ;) The systems were not really broken, just acting strange. And I am all for having things that are not absolutely necessary everywhere as soft dependencies, so you can build really small systems. It was just (too) hard to make this small system work as intended. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

Am Donnerstag, 22. Februar 2018, 10:25:11 schrieb Felix Miata:

IIRC, parts of Plasma5 *require* kde-oxygen-fonts as well.

That's not true since quite a while. Plasma5 uses the Noto and Hack fonts as default since about 1.5 years (the Noto fonts even since over two years). Not that it is very relevant to this discussion I think. The kde-fonts-oxygen package is 71 KB in size. Hardly a factor that decides whether some further desktop would fit onto the DVD or not, IMHO... The other two you mention are slightly bigger (171 KB and 575 KB respectively), but not many desktops would fit into that space either I assume. I seriously doubt that those fonts requirements are/were added to please some packager's ego though (as you imply), but rather to make sure things look as expected (or even readable), especially on a default installation without changing some font settings (and/or installing different fonts not on the DVD) manually... Whether the release notes would really need the google fonts I can't tell (especially considering that they are available as text-only version too), but I think there is a bug report about that anyway. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Johannes Meixner composed on 2018-02-23 14:37 (UTC+0100):

On Feb 23 14:15 Wolfgang Bauer wrote (excerpt):

...

Whether the release notes would really need the google fonts I can't tell (especially considering that they are available as text-only version too), but I think there is a bug report about that anyway.

right now I cannot find a bug report but see on the opensuse-packaging mailing list the mail thread about "release-notes-openSUSE requires google-opensans-fonts" e.g. starting at https://lists.opensuse.org/opensuse-packaging/2015-04/msg00070.html

https://bugzilla.opensuse.org/show_bug.cgi?id=926792 IN_PROGRESS last touched the day it was opened nearly 3 years ago. Assignee: Rick Salevsky -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 2018-02-20 at 15:50 +0100, Johannes Meixner wrote:

Hello,

On Feb 20 10:17 Stefan Seyfried wrote (excerpt):

...

Just "requires" and "recommends" without hints are not going to solve this.

I think "Requires" never needs a hint because only mandatory stuff (i.e. stuff without it can not at all work) should be required but "Recommends" need hints.

...

We either install too little (basically "--no-recommends") or too much. IMO the solver needs a hint, maybe "recommended also for smaller sytems" or "recommended, but only when you really want a seriously fat installation". Of course I have no idea how to implement that.

Only an offhanded idea:

Is it perhaps possible to specify conditions for "Recommends" e.g. in bar.spec something like ----------------------------------------------------------- %if %is_already_installed_or_will_get_now_installed foo Recommends: bar_addon_for_foo %endif -----------------------------------------------------------

This is basiclaly possible when using the reverse, Supplementes. for example gimp-plugin-aa contains: Supplements: packageand(gimp:libaa1) So if libaa1 is (for whatever reason) installed on the system, and also gimp is there, the the extension for gimp, making use of libaa1, is being installed as well (as recommended, and can be uninstalled on demand) (and there would be RPM rich deps, which Tumbleweed can't support just yet without breaking all update paths; hence not acceptable for the time being). Furthermore, if one goes to study how 'Recommends' is meant to be interpreter by the package manager [0], it becomes clear that 'Recommends is to be treated the same way as a Requires, with the exception that it is non-fatal if it can't be satisfied'. The other end to that is 'Suggests', which is not auto-installed, but a hint *can* be given to the user by a PM that additional packages are suggested. Cheers Dominique [0] http://rpm.org/user_doc/dependencies.html