[opensuse-packaging] How to handle -doc packages?
Hi, Some packages split out their man pages or other documentation into a sub package. More often than not that subpackage then is recommended. IOW installed by default which is undesirable. We also have a pattern for documenation though. So IMO it makes sense to link installing such documenation packages to the pattern. The question is how though. Assuming we have foo, foo-doc and patterns-base-documentation I see several ways: 1. pattern is in charge a. in patterns-base-documentation Recommends: foo-doc b. in patterns-base-documentation Recommends: foo-doc if foo 2. package is in charge a. in foo Recommends: foo-doc if patterns-base-documentation b. in foo-doc Supplements: packageand(foo:patterns-base-documentation) 1) pro: when looking at the pattern eg. in YaST one can actually see an overview of what documentation is available. con: pattern needs to be adjusted for every change in packaging. Extra step and easy to forget. 2) pro: packager can add, split, merge or drop packages any time con: package installation is a bit more black magic. The pattern leads to pulling in more packages than expected. Thoughts? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Ludwig, Ludwig Nussel <ludwig.nussel@suse.de> writes:
Hi,
Some packages split out their man pages or other documentation into a sub package. More often than not that subpackage then is recommended. IOW installed by default which is undesirable. We also have a pattern for documenation though. So IMO it makes sense to link installing such documenation packages to the pattern. The question is how though.
Assuming we have foo, foo-doc and patterns-base-documentation I see several ways:
1. pattern is in charge a. in patterns-base-documentation Recommends: foo-doc b. in patterns-base-documentation Recommends: foo-doc if foo
2. package is in charge a. in foo Recommends: foo-doc if patterns-base-documentation b. in foo-doc Supplements: packageand(foo:patterns-base-documentation)
1) pro: when looking at the pattern eg. in YaST one can actually see an overview of what documentation is available. con: pattern needs to be adjusted for every change in packaging. Extra step and easy to forget.
2) pro: packager can add, split, merge or drop packages any time con: package installation is a bit more black magic. The pattern leads to pulling in more packages than expected.
I would be in favor of 2), because 1) requires an additional step for every packager and thus will probably be skipped. Also, 2) should be verifiable via a rpmlint rule, whereas 1) isn't easily doable. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On 2020-02-20 10:31, Ludwig Nussel wrote:
Hi,
Some packages split out their man pages or other documentation into a sub package. More often than not that subpackage then is recommended. IOW installed by default which is undesirable. We also have a pattern for documenation though. So IMO it makes sense to link installing such documenation packages to the pattern. The question is how though.
Assuming we have foo, foo-doc and patterns-base-documentation I see several ways:
1. pattern is in charge a. in patterns-base-documentation Recommends: foo-doc b. in patterns-base-documentation Recommends: foo-doc if foo
2. package is in charge a. in foo Recommends: foo-doc if patterns-base-documentation b. in foo-doc Supplements: packageand(foo:patterns-base-documentation)
1) pro: when looking at the pattern eg. in YaST one can actually see an overview of what documentation is available. con: pattern needs to be adjusted for every change in packaging. Extra step and easy to forget.
2) pro: packager can add, split, merge or drop packages any time con: package installation is a bit more black magic. The pattern leads to pulling in more packages than expected.
Thoughts?
How this will play with rpm.install.excludedocs from /etc/zypp/zypp.conf now that there is a pattern involved, that can be installed or not? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
aplanas schrieb:
On 2020-02-20 10:31, Ludwig Nussel wrote:
Some packages split out their man pages or other documentation into a sub package. More often than not that subpackage then is recommended. IOW installed by default which is undesirable. We also have a pattern for documenation though. So IMO it makes sense to link installing such documenation packages to the pattern. The question is how though.
Assuming we have foo, foo-doc and patterns-base-documentation I see several ways:
1. pattern is in charge a. in patterns-base-documentation Recommends: foo-doc b. in patterns-base-documentation Recommends: foo-doc if foo
2. package is in charge a. in foo Recommends: foo-doc if patterns-base-documentation b. in foo-doc Supplements: packageand(foo:patterns-base-documentation)
1) pro: when looking at the pattern eg. in YaST one can actually see an overview of what documentation is available. con: pattern needs to be adjusted for every change in packaging. Extra step and easy to forget.
2) pro: packager can add, split, merge or drop packages any time con: package installation is a bit more black magic. The pattern leads to pulling in more packages than expected.
Thoughts?
How this will play with rpm.install.excludedocs from /etc/zypp/zypp.conf now that there is a pattern involved, that can be installed or not?
To the best of my knowledge neither zypper nor rpm not know that a package is "documenation package", that's purely convention. Only individual files are flagged as documenation. The excludedocs rpm setting prevents such files from getting installed but not the actual package containing them. So there's no change to current behavior. With excludedocs enabled both the pattern and the doc package could still get installed, albeit without any files ending up on disk. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2/20/20 10:31 AM, Ludwig Nussel wrote:
Hi,
Some packages split out their man pages or other documentation into a sub package. More often than not that subpackage then is recommended. IOW installed by default which is undesirable. We also have a pattern for documenation though. So IMO it makes sense to link installing such documenation packages to the pattern. The question is how though.
Assuming we have foo, foo-doc and patterns-base-documentation I see several ways:
1. pattern is in charge a. in patterns-base-documentation Recommends: foo-doc b. in patterns-base-documentation Recommends: foo-doc if foo
2. package is in charge a. in foo Recommends: foo-doc if patterns-base-documentation b. in foo-doc Supplements: packageand(foo:patterns-base-documentation)
1) pro: when looking at the pattern eg. in YaST one can actually see an overview of what documentation is available. con: pattern needs to be adjusted for every change in packaging. Extra step and easy to forget.
2) pro: packager can add, split, merge or drop packages any time con: package installation is a bit more black magic. The pattern leads to pulling in more packages than expected.
Thoughts?
There is no way to have option 1 without complete disaster, so having the packager in control through option 2 is preferred, but to the user option 1 is preferred. So how about Yet Another Bot harvesting the packages supplementing patterns-base-documentation to recommend back from the pattern - creating a SR every week? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Stephan Kulow schrieb:
On 2/20/20 10:31 AM, Ludwig Nussel wrote:
Some packages split out their man pages or other documentation into a sub package. More often than not that subpackage then is recommended. IOW installed by default which is undesirable. We also have a pattern for documenation though. So IMO it makes sense to link installing such documenation packages to the pattern. The question is how though.
Assuming we have foo, foo-doc and patterns-base-documentation I see several ways:
1. pattern is in charge a. in patterns-base-documentation Recommends: foo-doc b. in patterns-base-documentation Recommends: foo-doc if foo
2. package is in charge a. in foo Recommends: foo-doc if patterns-base-documentation b. in foo-doc Supplements: packageand(foo:patterns-base-documentation)
1) pro: when looking at the pattern eg. in YaST one can actually see an overview of what documentation is available. con: pattern needs to be adjusted for every change in packaging. Extra step and easy to forget.
2) pro: packager can add, split, merge or drop packages any time con: package installation is a bit more black magic. The pattern leads to pulling in more packages than expected.
Thoughts?
There is no way to have option 1 without complete disaster, so having the packager in control through option 2 is preferred, but to the user option 1 is preferred. So how about Yet Another Bot harvesting the packages supplementing patterns-base-documentation to recommend back from the pattern - creating a SR every week?
Could be done with some effort but the benefit would be that the method could also work for the 32bit packages where the approach is currently rather brute force. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Thu, 20 Feb 2020, Ludwig Nussel wrote:
Some packages split out their man pages or other documentation into a sub package.
I sure hope that the english manpage is part of the package containing the executable by default (and marked as doc file, if must be), and only additional documentation be split out into extra packages. At least for command line programs. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Feb 20, 2020 at 8:54 AM Michael Matz <matz@suse.de> wrote:
Hello,
On Thu, 20 Feb 2020, Ludwig Nussel wrote:
Some packages split out their man pages or other documentation into a sub package.
I sure hope that the english manpage is part of the package containing the executable by default (and marked as doc file, if must be), and only additional documentation be split out into extra packages. At least for command line programs.
RPM automatically marks files installed into %_docdir and %_mandir as documentation files. I *think* that's also the case for %_infodir files, but I am not sure. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz schrieb:
On Thu, 20 Feb 2020, Ludwig Nussel wrote:
Some packages split out their man pages or other documentation into a sub package.
I sure hope that the english manpage is part of the package containing the executable by default (and marked as doc file, if must be), and only additional documentation be split out into extra packages. At least for command line programs.
bash for example had the man pages in a separate package the last 13 years already :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2/20/20 3:51 PM, Ludwig Nussel wrote:
Michael Matz schrieb:
On Thu, 20 Feb 2020, Ludwig Nussel wrote:
Some packages split out their man pages or other documentation into a sub package.
I sure hope that the english manpage is part of the package containing the executable by default (and marked as doc file, if must be), and only additional documentation be split out into extra packages. At least for command line programs.
bash for example had the man pages in a separate package the last 13 years already :-)
... and not being installed by default for 5 months. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Thu, 20 Feb 2020, Ludwig Nussel wrote:
Michael Matz schrieb:
On Thu, 20 Feb 2020, Ludwig Nussel wrote:
Some packages split out their man pages or other documentation into a sub package.
I sure hope that the english manpage is part of the package containing the executable by default (and marked as doc file, if must be), and only additional documentation be split out into extra packages. At least for command line programs.
bash for example had the man pages in a separate package the last 13 years already :-)
Yes. My point is that this is not a good state of affairs. If the respective package containing the manpage is installed by default together with the main package (as was the case most of those 13 years for bash), it doesn't matter as much. But if it's not installed anymore by default I consider this a quality-of-implementation bug. (Note that for command line programs I specifically make a difference between man-pages (plus perhaps info-pages in some cases) and all other documentation (which e.g. bash has as well)). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 20.02.20 um 17:00 schrieb Michael Matz:
Yes. My point is that this is not a good state of affairs. If the respective package containing the manpage is installed by default together with the main package (as was the case most of those 13 years for bash), it doesn't matter as much. But if it's not installed anymore by default I consider this a quality-of-implementation bug.
(Note that for command line programs I specifically make a difference between man-pages (plus perhaps info-pages in some cases) and all other documentation (which e.g. bash has as well)).
We can still have the documentation pattern being installed by default on a regular install. But what Ludwig is rightfully aiming at is breaking with the 'one solution for all' - what is right for the system you're working on is not necessarily right for the system you run your crypto miner on. And disabling recommends is a very big hammer - and --excludedocs is a crude workaround only applicable in some situations. Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz schrieb:
On Thu, 20 Feb 2020, Ludwig Nussel wrote:
Michael Matz schrieb:
On Thu, 20 Feb 2020, Ludwig Nussel wrote:
Some packages split out their man pages or other documentation into a sub package.
I sure hope that the english manpage is part of the package containing the executable by default (and marked as doc file, if must be), and only additional documentation be split out into extra packages. At least for command line programs.
bash for example had the man pages in a separate package the last 13 years already :-)
Yes. My point is that this is not a good state of affairs. If the respective package containing the manpage is installed by default together with the main package (as was the case most of those 13 years for bash), it doesn't matter as much. But if it's not installed anymore by default I consider this a quality-of-implementation bug.
(Note that for command line programs I specifically make a difference between man-pages (plus perhaps info-pages in some cases) and all other documentation (which e.g. bash has as well)).
For bash the documenation was probably split out due to it's size in comparison to the actual binaries. There is even an rpmlint check for that: https://rpmlint.opensuse.org/openSUSE:Factory/x86_64/standard?rule=package-w... That one doesn't differentiate between man/info pages and other formats like html though AFAIK. Maybe that's the mistake. Indeed in bash-doc the man pages are just 100k vs 1.8MB for the rest. So man pages back into bash itself I guess. Another less clear case is perl-doc. It contains API documentation. Not sure where to reasonably split. Maybe at least perl(1) and perlrun(1) should go back to the main package while the perldoc binary (referenced by perl(1)) could go into the -doc subpackage. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello Ludwig, On Mon, 24 Feb 2020, Ludwig Nussel wrote:
bash for example had the man pages in a separate package the last 13 years already :-)
Yes. My point is that this is not a good state of affairs. If the respective package containing the manpage is installed by default together with the main package (as was the case most of those 13 years for bash), it doesn't matter as much. But if it's not installed anymore by default I consider this a quality-of-implementation bug.
(Note that for command line programs I specifically make a difference between man-pages (plus perhaps info-pages in some cases) and all other documentation (which e.g. bash has as well)). ... That one doesn't differentiate between man/info pages and other formats like html though AFAIK. Maybe that's the mistake.
That's my thinking, yes.
Indeed in bash-doc the man pages are just 100k vs 1.8MB for the rest. So man pages back into bash itself I guess.
Another less clear case is perl-doc. It contains API documentation. Not sure where to reasonably split. Maybe at least perl(1) and perlrun(1) should go back to the main package while the perldoc binary (referenced by perl(1)) could go into the -doc subpackage.
Perhaps something like that, yeah. Not the worst idea. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Sorry for my stupid question, but what problem exactly do you want to solve? Lars -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Lars Vogdt schrieb:
Sorry for my stupid question, but what problem exactly do you want to solve?
The need to use --no-recommends to avoid bloat. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2/21/20 9:58 AM, Ludwig Nussel wrote:
Lars Vogdt schrieb:
Sorry for my stupid question, but what problem exactly do you want to solve?
The need to use --no-recommends to avoid bloat.
Hi Ludwig, If that's your goal, I can only recommend (pun intended) to avoid the word bloat. bloat is a very negative word ("unwarranted or excessive growth or enlargement") that does not match to man pages for many, many people. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2/21/20 11:18 AM, Stephan Kulow wrote:
If that's your goal, I can only recommend (pun intended) to avoid the word bloat. bloat is a very negative word ("unwarranted or excessive growth or enlargement") that does not match to man pages for many, many people.
off-topic, but this is not a very negative word. It's very commonly used in software world https://en.wikipedia.org/wiki/Software_bloat Cheers, Adam -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Feb 21, 2020 at 6:56 AM Adam Majer <amajer@suse.de> wrote:
On 2/21/20 11:18 AM, Stephan Kulow wrote:
If that's your goal, I can only recommend (pun intended) to avoid the word bloat. bloat is a very negative word ("unwarranted or excessive growth or enlargement") that does not match to man pages for many, many people.
off-topic, but this is not a very negative word. It's very commonly used in software world
It is often used in a negative context as a negative pejorative. It is even noted as such in the first paragraph of that Wikipedia article. Generally speaking, it is a *very* negative way to present software features and scope. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2/21/20 12:56 PM, Adam Majer wrote:
On 2/21/20 11:18 AM, Stephan Kulow wrote:
If that's your goal, I can only recommend (pun intended) to avoid the word bloat. bloat is a very negative word ("unwarranted or excessive growth or enlargement") that does not match to man pages for many, many people.
off-topic, but this is not a very negative word. It's very commonly used in software world
Aehm, our reading of that article seem to be very different - to read from it a positive meaning is beyond me. But let me quote from it to underline my point:
In his 2001 essay Strategy Letter IV: Bloatware and the 80/20 Myth,[3] Joel Spolsky argues that while 80% of the users > only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss the one or two special features that are present in the "bloated" version.
So whatever is "bloat" to Ludwig is essential to others. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2/21/20 1:34 PM, Stephan Kulow wrote:
On 2/21/20 12:56 PM, Adam Majer wrote:
On 2/21/20 11:18 AM, Stephan Kulow wrote:
If that's your goal, I can only recommend (pun intended) to avoid the word bloat. bloat is a very negative word ("unwarranted or excessive growth or enlargement") that does not match to man pages for many, many people.
off-topic, but this is not a very negative word. It's very commonly used in software world
Aehm, our reading of that article seem to be very different - to read from it a positive meaning is beyond me.
Bloat, in isolation, is not a negative word. It's a word. When someone complains about bloated software, then you need to look at the context and not just attack the usage of the word - bloat. And to me that appeared to be the case. That was my point.
But let me quote from it to underline my point:
In his 2001 essay Strategy Letter IV: Bloatware and the 80/20 Myth,[3] Joel Spolsky argues that while 80% of the users > only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss the one or two special features that are present in the "bloated" version.
So whatever is "bloat" to Ludwig is essential to others.
Yes, it's very subjective. What I would consider bloat in a container is very important on a dev machine -- like, documentation ;) I've had a discussion with some people outside of openSUSE where they ship some JS files but they don't ship documentation. To them including documentation in a package would be bloat while to me it would be essential part of the package (or subpackage) and shipping JS without documentation makes shipping said JS quite useless in the first place. - Adam -- Adam Majer - amajer@suse.de SUSE Software Solutions Germany GmbH HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, 21 Feb 2020 09:58:48 +0100 Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Sorry for my stupid question, but what problem exactly do you want to solve?
The need to use --no-recommends to avoid bloat.
Recommends ARE bloat, as they are (per definition) not required to run the software. If you (or anyone else) really don't want to get recommended packages, why don't you set: installRecommends = no in /etc/zypp/zypper.conf and be happy? I do this for my servers since years and avoid all the "bloat" you mention. If I really want something that is just recommended, it's anyway just a "zypper install" away. Yes, this is sometimes extra work, but it's worth the price as you get only what you pay for... ;-) For appliance builds, it shouldn't also be that hard to have recommends off by default and "require" the really wanted (recommended) packages in your package list. But to make you idea more complex, I also have a 3rd proposal: 3) avoid to recommend doc packages - use the appropriate Group tag in RPM to get them shown in YaST. Oh, sorry: we don't have Group tags in RPM any longer (did I tell everyone often enough that I still think this was a bad idea? ;-) Therefor: packagers, who want to get their doc-packages visible, could request to get them added (as recommended?) into the documentation-pattern Pro: + packagers can decide, if their doc-package should become prominently visible (in the pattern) + as long as the package contains the name of the main package, it will be shown to end-users if they search for it + "bloat" get's reduced, as doc-packages are not selected automatically any longer. But the package could be installed later, if the users notices that he wants/needs it. Con: + users have to explicitely install the -doc subpackages. There will be no magic who installs them, unless the user selects the documentation-pattern *and* the packager added their doc-package there. + packagers have to take care that their -doc packages get recommended in the documentation pattern Alternative 1: someone writes a script that grabs for "*-doc, *-documentation, *-manual" an puts the results in there Alternative 2: someone enhances YaST to do so automatically (something similar like "Show -devel packages", but now with "Show -doc packages") ----- ...but I still think that disabling recommends for special conditions might be the best solution. I can even imagine to have: * Desktop install => set "installRecommends = yes" * Server install => set "installRecommends = no" * Container install => set "installRecommends = no" But here we are (again) in the discussion about dedicated installation workflows for specific use-cases. And installation of -doc packages is there just a very small part of the discussion. With kind regards, Lars -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
21.02.2020 15:00, Lars Vogdt пишет:
On Fri, 21 Feb 2020 09:58:48 +0100 Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Sorry for my stupid question, but what problem exactly do you want to solve?
The need to use --no-recommends to avoid bloat.
Recommends ARE bloat, as they are (per definition) not required to run the software.
That is not true as long as recommends are installed by default by majority of users and while installRecommends is default mode for testing distribution. Nobody knows whether Recommends are essential or optional (not in the strict package management sense but from usability point of view).
If you (or anyone else) really don't want to get recommended packages, why don't you set: installRecommends = no in /etc/zypp/zypper.conf and be happy?
Then turn off installRecomends by default. So far every complaint that disabling installRecommends breaks things that I have seen on this list or in bugzilla ends up with "if you disable installRecommends you are on your own" which effectively makes Recommends mandatory. If they are truly optional why they are enabled by default in the first place? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, 21 Feb 2020 18:22:49 +0300 Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Recommends ARE bloat, as they are (per definition) not required to run the software.
That is not true as long as recommends are installed by default by majority of users and while installRecommends is default mode for testing distribution.
...and I don't say anything against this. If we build for a desktop system, users probably always want "the latest and greatest" "more" of it. Enabling and installing Recommends (and maybe even Suggests) makes sense here. But not for specific use cases like containers or even servers.
If you (or anyone else) really don't want to get recommended packages, why don't you set: installRecommends = no in /etc/zypp/zypper.conf and be happy?
Then turn off installRecomends by default.
That's not exaclty my point: I want to turn it off, where we/you identified special needs.
So far every complaint that disabling installRecommends breaks things that I have seen on this list or in bugzilla ends up with "if you disable installRecommends you are on your own" which effectively makes Recommends mandatory.
Which I would question (in regard towards those who tell you that: "Recommends have to be installed"). But I think that this is another topic, which is independent from Ludwig's current topic. With kind regards, Lars -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Donnerstag, 20. Februar 2020, 10:31:12 CET schrieb Ludwig Nussel:
Hi,
Some packages split out their man pages or other documentation into a sub package. More often than not that subpackage then is recommended. IOW installed by default which is undesirable. We also have a pattern for documenation though. So IMO it makes sense to link installing such documenation packages to the pattern. The question is how though.
+1 for any option, that improves doc handling. While at it, the biggest bloat of a typical (smallish) installion is translations. I've started to search all -lang packages in preparation of an installation and deactivate them. I don't like cli translations anyway. It would be nice to expose an option, that avoids installing translations. As discussed before, alternatively a filter for rpm to just install the files of certain languages from any language pack is another de-bloating option, that's missing badly, IMHO. Cheers, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hans-Peter Jansen schrieb:
[...] While at it, the biggest bloat of a typical (smallish) installion is translations. I've started to search all -lang packages in preparation of an installation and deactivate them. I don't like cli translations anyway.
Differnent topic and partially and solved via %lang_package macro already: 15.1: $ rpm -q --recommends bash bash-doc = 4.4 bash-lang = 4.4 $ rpm -q --supplements bash-lang bash TW: $ rpm -q --supplements bash-lang $ rpm -q --recommends bash $ rpm -q --provides bash-lang bash-lang = 5.0.11-3.2 bash-lang-all = 5.0.11 locale(bash:bg) locale(bash:ca) locale(bash:cs) [...] IOW bash-lang only gets pulled in when the system is set to one of the provided locales. Not sure if it works 100% with bash-lang though. It has files for that weird en@quot and en@boldquot locale. You'd still get the full -lang package even though you likely only need one. Could be tweaked further via %_install_langs but that would result in partially installed rpms iow breaks delta rpms. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dear Ludwig, sorry to reply to such an old thread, but facing an issue, that relates.. Am Montag, 24. Februar 2020, 10:13:40 CEST schrieb Ludwig Nussel:
Differnent topic and partially and solved via %lang_package macro already:
15.1: $ rpm -q --recommends bash bash-doc = 4.4 bash-lang = 4.4 $ rpm -q --supplements bash-lang bash
TW: $ rpm -q --supplements bash-lang $ rpm -q --recommends bash $ rpm -q --provides bash-lang bash-lang = 5.0.11-3.2 bash-lang-all = 5.0.11 locale(bash:bg) locale(bash:ca) locale(bash:cs) [...]
IOW bash-lang only gets pulled in when the system is set to one of the provided locales. Not sure if it works 100% with bash-lang though. It has files for that weird en@quot and en@boldquot locale.
I stumbled across a case, where this doesn't work as advertised: Current Blender for TW uses a plain %lang_package, but: $ rpm -q --provides blender-lang blender-lang = 2.83.2-361.1 blender-lang-all = 2.83.2 This is from my build at home:frispete:blender but it's similar to graphics/ blender and what is in Factory. Blender packages the translation file in a non-standard directory: $ rpm -ql --provides blender-lang | grep -E '\<de\>' /usr/share/blender/2.83/datafiles/locale/de /usr/share/blender/2.83/datafiles/locale/de/LC_MESSAGES /usr/share/blender/2.83/datafiles/locale/de/LC_MESSAGES/blender.mo which might be the reason for the locale(blender:de) tags being missing, and consequently doesn't pull in blender-lang for a usual installation with matching locales for TW at least. Okay, casual Blender users (e.g. my 14 years old son) refrain from using a localized Blender anyway, but that's another topic ;-) I'm going to add a "Recommends: %name-lang = %version" again for now. It might be interesting, why this doesn't work correctly for TW, as this may affect other packages as well.. Cheers, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hans-Peter Jansen wrote:
[...] Current Blender for TW uses a plain %lang_package, but:
$ rpm -q --provides blender-lang blender-lang = 2.83.2-361.1 blender-lang-all = 2.83.2
This is from my build at home:frispete:blender but it's similar to graphics/ blender and what is in Factory.
Blender packages the translation file in a non-standard directory:
$ rpm -ql --provides blender-lang | grep -E '\<de\>' /usr/share/blender/2.83/datafiles/locale/de /usr/share/blender/2.83/datafiles/locale/de/LC_MESSAGES /usr/share/blender/2.83/datafiles/locale/de/LC_MESSAGES/blender.mo
which might be the reason for the locale(blender:de) tags being missing, and consequently doesn't pull in blender-lang for a usual installation with matching locales for TW at least.
Yes. The file attr only matches on /usr/share/locale so far: https://github.com/openSUSE/rpm-config-SUSE/blob/master/fileattrs/locale.att... The script actually extracting the information would work with the blender layout though: https://github.com/openSUSE/rpm-config-SUSE/blob/master/scripts/locale.prov Indeed there are quite some packages that do not install their translations to the standard location: $ zcat ARCHIVES.gz|awk '$0 ~ /locale\/[^/]+\/LC_MESSAGES\/.*\.mo$/ && $0 !~ /\/usr\/share\/locale/ {print $1}'|sort -u [...] ./i586/gnome-keysign-0.9.7.2-2.2.i586.rpm: ./i586/grass-7.8.3-1.4.i586.rpm: ./i586/hawk2-2.2.0+git.1593701652.5c1edcf8-1.1.i586.rpm: ./i586/kbd-2.2.0-2.2.i586.rpm: ./i586/openscad-2019.05-2.3.i586.rpm: ./i586/python3-wxPython-lang-4.1.0-2.1.i586.rpm: ./i586/ruby2.6-rubygem-gettext-3.3.5-1.2.i586.rpm: ./i586/ruby2.6-rubygem-gettext-testsuite-3.3.5-1.2.i586.rpm: ./i586/ruby2.7-rubygem-gettext-3.3.5-1.2.i586.rpm: ./i586/ruby2.7-rubygem-gettext-testsuite-3.3.5-1.2.i586.rpm: ./i586/rubygem-gettext_activerecord-2.1.0-17.18.i586.rpm: ./i586/rubygem-gettext_activerecord-testsuite-2.1.0-17.18.i586.rpm: ./i586/sarg-2.4.0-3.1.i586.rpm: ./i586/spyder-terminal-0.3.2-1.1.i586.rpm: ./i586/starfighter-2.0.0.3-1.2.i586.rpm: ./i586/WoeUSB-3.3.1-1.2.i586.rpm: ./i586/yudit-2.9.6-3.12.i586.rpm: ./i586/zabbix-phpfrontend-4.0.19-1.3.i586.rpm: ./noarch/blender-lang-2.83.1-1.1.noarch.rpm: ./noarch/epymc-lang-1.2.0-2.5.noarch.rpm: ./noarch/gnome-shell-extension-desktop-icons-20.04.0-2.1.noarch.rpm: ./noarch/gnome-shell-extension-hamster-time-tracker-0.10.0_3.36-5.1.noarch.rpm: ./noarch/gnuhealth-client-3.6.9-1.1.noarch.rpm: ./noarch/gnulib-devel-git.20200216.f4693b016-1.2.noarch.rpm: ./noarch/icingaweb2-2.8.1-1.1.noarch.rpm: ./noarch/icingaweb2-common-2.8.1-1.1.noarch.rpm: ./noarch/icingaweb2-module-director-1.7.2-1.2.noarch.rpm: ./noarch/phpMyAdmin-4.9.5-4.1.noarch.rpm: ./noarch/postfixadmin-3.2-2.4.noarch.rpm: ./noarch/python3-colander-1.7.0-5.1.noarch.rpm: ./noarch/python3-Django-3.0.7-1.2.noarch.rpm: ./noarch/python3-django-allauth-0.42.0-1.1.noarch.rpm: ./noarch/python3-django-avatar-5.0.0-1.3.noarch.rpm: ./noarch/python3-django-contrib-comments-1.9.2-1.3.noarch.rpm: ./noarch/python3-django-countries-6.1.2-1.1.noarch.rpm: ./noarch/python3-django-debug-toolbar-2.2-1.2.noarch.rpm: ./noarch/python3-django-extensions-3.0.2-1.1.noarch.rpm: ./noarch/python3-django-filter-2.3.0-1.1.noarch.rpm: ./noarch/python3-django-formtools-2.2-1.2.noarch.rpm: ./noarch/python3-django-guardian-2.3.0-1.1.noarch.rpm: ./noarch/python3-django-model-utils-4.0.0-1.2.noarch.rpm: ./noarch/python3-django-oidc-provider-0.7.0-2.1.noarch.rpm: ./noarch/python3-django-phonenumber-field-4.0.0-1.1.noarch.rpm: ./noarch/python3-django-q-1.3.1-1.1.noarch.rpm: ./noarch/python3-django-registration-3.1-2.1.noarch.rpm: ./noarch/python3-djangorestframework-3.11.0-1.5.noarch.rpm: ./noarch/python3-django-reversion-3.0.7-1.3.noarch.rpm: ./noarch/python3-django-rosetta-0.9.4-1.2.noarch.rpm: ./noarch/python3-django-sortedm2m-3.0.0-1.1.noarch.rpm: ./noarch/python3-django-treebeard-4.3.1-1.1.noarch.rpm: ./noarch/python3-humanize-2.4.0-1.1.noarch.rpm: ./noarch/python3-IMDbPY-6.8-1.5.noarch.rpm: ./noarch/python3-Sphinx2-2.3.1-1.3.noarch.rpm: ./noarch/python3-Sphinx-3.0.4-1.1.noarch.rpm: ./noarch/python3-tap.py-3.0-2.1.noarch.rpm: ./noarch/python3-WTForms-2.2.1-1.3.noarch.rpm: ./noarch/reuse-0.8.0-1.2.noarch.rpm: ./noarch/spyder-lang-4.1.3-3.1.noarch.rpm: ./noarch/weblate-4.1.1-1.1.noarch.rpm: ./noarch/widelands-data-build20-3.3.noarch.rpm: ./noarch/yast2-trans-af-84.87.20200627.7af6bd201f-1.1.noarch.rpm: [...] ./noarch/yast2-trans-zu-84.87.20200627.7af6bd201f-1.1.noarch.rpm: ./noarch/youtube-dl-gui-lang-0.4-1.8.noarch.rpm: ./x86_64/gnome-keysign-0.9.7.2-2.2.x86_64.rpm: ./x86_64/grass-7.8.3-1.4.x86_64.rpm: ./x86_64/hawk2-2.2.0+git.1593701652.5c1edcf8-1.1.x86_64.rpm: ./x86_64/kbd-2.2.0-2.2.x86_64.rpm: ./x86_64/openscad-2019.05-2.3.x86_64.rpm: ./x86_64/python3-wxPython-lang-4.1.0-2.1.x86_64.rpm: ./x86_64/ruby2.6-rubygem-gettext-3.3.5-1.2.x86_64.rpm: ./x86_64/ruby2.6-rubygem-gettext-testsuite-3.3.5-1.2.x86_64.rpm: ./x86_64/ruby2.7-rubygem-gettext-3.3.5-1.2.x86_64.rpm: ./x86_64/ruby2.7-rubygem-gettext-testsuite-3.3.5-1.2.x86_64.rpm: ./x86_64/rubygem-gettext_activerecord-2.1.0-17.18.x86_64.rpm: ./x86_64/rubygem-gettext_activerecord-testsuite-2.1.0-17.18.x86_64.rpm: ./x86_64/sarg-2.4.0-3.1.x86_64.rpm: ./x86_64/spyder-terminal-0.3.2-1.1.x86_64.rpm: ./x86_64/starfighter-2.0.0.3-1.2.x86_64.rpm: ./x86_64/WoeUSB-3.3.1-1.2.x86_64.rpm: ./x86_64/yudit-2.9.6-3.12.x86_64.rpm: ./x86_64/zabbix-phpfrontend-4.0.19-1.3.x86_64.rpm: So I guess it makes sense to relax the regexp to not limit the match to /usr/share/locale. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (10)
-
Adam Majer -
Andrei Borzenkov -
aplanas -
Dan Čermák -
Hans-Peter Jansen -
Lars Vogdt -
Ludwig Nussel -
Michael Matz -
Neal Gompa -
Stephan Kulow