I just recieved one of these bugs (#492446), and I'm not sure why we'd do this for any package.
If we split the docs like this:
- it would be inconsistent per-package -- so an admin wouldn't know whether a package had docs or not in the main package without manually trying to install a foo-doc subpackage -- they would no longer be there by default if they're needed
Hence, why do this, when rpm already has a --nodocs flag and macro that can be used for space savings on live images?
Bill
On Thu, 26 Mar 2009, Bill Nottingham wrote:
I just recieved one of these bugs (#492446), and I'm not sure why we'd do this for any package.
If we split the docs like this:
- it would be inconsistent per-package
-- so an admin wouldn't know whether a package had docs or not in the main package without manually trying to install a foo-doc subpackage -- they would no longer be there by default if they're needed
Hence, why do this, when rpm already has a --nodocs flag and macro that can be used for space savings on live images?
yum's tsflags option in yum.conf also accepts 'nodocs'
unfortunately, if you're using rpm -V it won't know about --nodocs being passed in on install.
-sv
On Thu, 26 Mar 2009, Seth Vidal wrote:
On Thu, 26 Mar 2009, Bill Nottingham wrote:
I just recieved one of these bugs (#492446), and I'm not sure why we'd do this for any package.
If we split the docs like this:
- it would be inconsistent per-package
-- so an admin wouldn't know whether a package had docs or not in the main package without manually trying to install a foo-doc subpackage -- they would no longer be there by default if they're needed
Hence, why do this, when rpm already has a --nodocs flag and macro that can be used for space savings on live images?
yum's tsflags option in yum.conf also accepts 'nodocs'
unfortunately, if you're using rpm -V it won't know about --nodocs being passed in on install.
Sure it does:
[root@localhost ~]# rpm -U --nodocs /tmp/telnet-0.17-42.fc9.x86_64.rpm [root@localhost ~]# rpm -qs telnet normal /usr/bin/telnet not installed /usr/share/man/man1/telnet.1.gz [root@localhost ~]# rpm -V telnet [root@localhost ~]#
Verify checks out clean as the recorded file state says the file is not even *supposed* to be there. Compared to manually removing it:
[root@localhost ~]# rpm -U /tmp/telnet-0.17-42.fc9.x86_64.rpm [root@localhost ~]# rm -f /usr/share/man/man1/telnet.1.gz [root@localhost ~]# rpm -qs telnet normal /usr/bin/telnet normal /usr/share/man/man1/telnet.1.gz [root@localhost ~]# rpm -V telnet missing d /usr/share/man/man1/telnet.1.gz [root@localhost ~]#
- Panu -
On Thu, 2009-03-26 at 16:14 -0400, Bill Nottingham wrote:
Hence, why do this, when rpm already has a --nodocs flag and macro that can be used for space savings on live images?
I don't think --nodocs flags will remove the deps that are there just to render the docs, if that is a concern.
Jesse Keating (jkeating@redhat.com) said:
On Thu, 2009-03-26 at 16:14 -0400, Bill Nottingham wrote:
Hence, why do this, when rpm already has a --nodocs flag and macro that can be used for space savings on live images?
I don't think --nodocs flags will remove the deps that are there just to render the docs, if that is a concern.
I think the main concern was just space. So, looking at the bugs filed, the documentation takes ~86MB, ~36MB squashed. Most all of that is the cloudy package (a bunch of PDFs), octave (which includes the docs in *BOTH* PDF and HTML form for the main manual, and one seperate document in PDF, DVI, PS, HTML, Texinfo, and info form!), and wxPython (9MB of samples and demos).
I suspect it's much simpler to weed out extraneous docs than to worry about splitting off random -doc packages inconsistently.
Bill
On Thu, 2009-03-26 at 16:14 -0400, Bill Nottingham wrote:
I just recieved one of these bugs (#492446), and I'm not sure why we'd do this for any package.
If we split the docs like this:
- it would be inconsistent per-package
-- so an admin wouldn't know whether a package had docs or not in the main package without manually trying to install a foo-doc subpackage -- they would no longer be there by default if they're needed
Hence, why do this, when rpm already has a --nodocs flag and macro that can be used for space savings on live images?
My personal feeling is that this is nice in some cases, but not the majority. If/when we have "Suggests:" I think it'd be a perfect opportunity to use it on *-docs, until then the only thing I'd recommend is that people not do rpm installs, or use tsflag hacks :).
On Thu, Mar 26, 2009 at 4:14 PM, Bill Nottingham wrote:
I just recieved one of these bugs (#492446), and I'm not sure why we'd do this for any package.
If we split the docs like this:
- it would be inconsistent per-package
-- so an admin wouldn't know whether a package had docs or not in the main package without manually trying to install a foo-doc subpackage -- they would no longer be there by default if they're needed
Hence, why do this, when rpm already has a --nodocs flag and macro that can be used for space savings on live images?
Bill
There is another inconsistency. Some -doc subpackages in Fedora require the main package and some don't. I don't know what someone can do with, for instance, API docs of a library without having the library itself. But I don't see a guideline that tells that a -doc subpackage must require the main package.
Orcan
On Thu, 26 Mar 2009 17:24:21 -0400, Orcan wrote:
There is another inconsistency. Some -doc subpackages in Fedora require the main package and some don't. I don't know what someone can do with, for instance, API docs of a library without having the library itself.
You can browse the API documentation and evaluate it, then decide whether you want to develop with the library.
But I don't see a guideline that tells that a -doc subpackage must require the main package.
And that's good.
On Thu, 2009-03-26 at 22:34 +0100, Michael Schwendt wrote:
On Thu, 26 Mar 2009 17:24:21 -0400, Orcan wrote:
There is another inconsistency. Some -doc subpackages in Fedora require the main package and some don't. I don't know what someone can do with, for instance, API docs of a library without having the library itself.
You can browse the API documentation and evaluate it, then decide whether you want to develop with the library.
Or read the documentation to some piece of software on a faster/better/more local machine, that's in use on a headless server somewhere on the other side of an overburdened internet link.
Kevin Kofler (kevin.kofler@chello.at) said:
Bill Nottingham wrote:
I just recieved one of these bugs (#492446), and I'm not sure why we'd do this for any package.
Because the documentation can be noarch. We have support for noarch subpackages in F10 and later now.
Sure, but either:
- you have the main package reqire the doc package (in which case, whoop de do, a split out 400k package) - you don't, in which case you break the user experience
Bill
Bill Nottingham wrote:
I just recieved one of these bugs (#492446), and I'm not sure why we'd do this for any package.
If we split the docs like this:
- it would be inconsistent per-package
-- so an admin wouldn't know whether a package had docs or not in the main package without manually trying to install a foo-doc subpackage -- they would no longer be there by default if they're needed
Hence, why do this, when rpm already has a --nodocs flag and macro that can be used for space savings on live images?
If the docs are large it can be a win because the end user doesn't have to download the docs(in the rpm) before it gets installed. Also the use case of a -docs subpackage is when you want to exclude the docs for a single package rather than for every package on the system.
In the specific bug you cite I agree with you: 1) --nodocs seems like a better choice for live media. 2) 1 MB doesn't seem excessively large in terms of download size so the case for a -docs subpackage seems a little weak.
-Toshio
On Mon, 2009-03-30 at 13:39 -0500, Toshio Kuratomi wrote:
In the specific bug you cite I agree with you: 1) --nodocs seems like a better choice for live media.
I'm not sure about that one: If you install the live media to disk, the documentation bits are missing and it's hard to get them back (short of reinstalling every package that has documentation in it).
Nils
Nils Philippsen wrote:
I'm not sure about that one: If you install the live media to disk, the documentation bits are missing and it's hard to get them back (short of reinstalling every package that has documentation in it).
Yeah, I don't think using hacks which omit parts of packages is a good idea for the live images.
Kevin Kofler
devel@lists.stg.fedoraproject.org