3:14 p.m.
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
3:15 p.m.
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
8:13 a.m.
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 -
3:22 p.m.
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
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:42 p.m.
Jesse Keating (jkeating(a)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
4:12 p.m.
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 :).
--
James Antill <james(a)fedoraproject.org>
Fedora
4:24 p.m.
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
4:34 p.m.
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.
4:56 p.m.
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.
1:42 p.m.
Kevin Kofler (kevin.kofler(a)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
1:39 p.m.
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
4:29 a.m.
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 "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
9:54 a.m.
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
5498
days inactive
5503
days old
13 comments
11 participants
participants (11)
-
Bill Nottingham -
Callum Lerwick -
James Antill -
Jesse Keating -
Kevin Kofler -
Michael Schwendt -
Nils Philippsen -
Orcan Ogetbil -
Panu Matilainen -
Seth Vidal -
Toshio Kuratomi