I was just looking around at other packages to see what Group: tag should go on a -doc subpackage. It looks like Documentation is the right group, but I noticed that this is rather inconsistent in the official packages.
exim-doc Documentation gtk-doc Development/Tools kernel-doc Documentation nasm-doc Development/Languages selinux-doc System Environment/Base sendmail-doc Documentation tclx-doc Development/Languages tetex-doc Applications/Publishing tix-doc Development/Languages xorg-x11-doc Documentation
Given that the Group: tag is essentially meaningless, I wasn't sure this justified mention in bugzilla, but it probably should be fixed.
Steve
Steven Pritchard wrote :
I was just looking around at other packages to see what Group: tag should go on a -doc subpackage. It looks like Documentation is the right group, but I noticed that this is rather inconsistent in the official packages.
exim-doc Documentation gtk-doc Development/Tools kernel-doc Documentation nasm-doc Development/Languages selinux-doc System Environment/Base sendmail-doc Documentation tclx-doc Development/Languages tetex-doc Applications/Publishing tix-doc Development/Languages xorg-x11-doc Documentation
Given that the Group: tag is essentially meaningless, I wasn't sure this justified mention in bugzilla, but it probably should be fixed.
gtk-doc is a tool for managing documentation, so its category seems correct, OTOH for the others, changing to "Documentation" would seem to make sense. Note that indeed this tag is seldom used, but can actually become useful once surfaced, in a web interface or in a package management tool (synaptic uses it for instance).
Matthias
Matthias Saou wrote:
Steven Pritchard wrote :
Given that the Group: tag is essentially meaningless, I wasn't sure this justified mention in bugzilla, but it probably should be fixed.
...
Note that indeed this tag is seldom used, but can actually become useful once surfaced, in a web interface or in a package management tool (synaptic uses it for instance).
I'd like to see Group: tags correlate (IMO, strictly) with primary Menu location/labels.
-- Rex
On Fri, Jul 16, 2004 at 04:17:23PM +0200, Matthias Saou wrote:
gtk-doc is a tool for managing documentation, so its category seems correct, OTOH for the others, changing to "Documentation" would seem to make sense.
Oops. That's what I get for just doing rpm -qp *-doc-* without looking at all of the descriptions. :-)
Steve
Steven Pritchard wrote :
On Fri, Jul 16, 2004 at 04:17:23PM +0200, Matthias Saou wrote:
gtk-doc is a tool for managing documentation, so its category seems correct, OTOH for the others, changing to "Documentation" would seem to make sense.
Oops. That's what I get for just doing rpm -qp *-doc-* without looking at all of the descriptions. :-)
Not to mention that you missed all the *-docs-* packages ;-)
Matthias
Matthias Saou wrote:
Steven Pritchard wrote :
Oops. That's what I get for just doing rpm -qp *-doc-* without looking at all of the descriptions. :-)
Not to mention that you missed all the *-docs-* packages ;-)
Strike one for consistent naming :)
Mark Derricutt a écrit :
Matthias Saou wrote:
Steven Pritchard wrote :
Oops. That's what I get for just doing rpm -qp *-doc-* without looking at all of the descriptions. :-)
Not to mention that you missed all the *-docs-* packages ;-)
Strike one for consistent naming :)
+ apache manual I think...
Steven Pritchard wrote :
Oops. That's what I get for just doing rpm -qp *-doc-* without looking at all of the descriptions. :-)
Matthias Saou wrote:
Not to mention that you missed all the *-docs-* packages ;-)
Mark Derricutt wrote:
Strike one for consistent naming :)
My thought exactly.
On Sat, Jul 17, 2004 at 10:22:37AM +0200, Nicolas Mailhot wrote:
- apache manual I think...
Most of the rest of the documentation packages already have the right group.
gnome-user-docs Documentation iiimf-docs Documentation postgresql-docs Applications/Databases python-docs Documentation ruby-docs Documentation httpd-manual Documentation
So should those packages be renamed to whatever-doc (or *-doc be renamed to *-docs)? Or maybe we should just make sure all of the packages have a Provides: foo-doc[s] so getting the name wrong still works (at least for apt).
Steve
On Sat, 2004-07-17 at 19:19, Steven Pritchard wrote:
So should those packages be renamed to whatever-doc (or *-doc be renamed to *-docs)?
FC3test1: 10 * -doc, 5 * -docs, 1 * -manual. fedora.us: 2 * -doc, 2 * -docs, 0 * -manual. rpmseek.com: 1204 * -doc, 129 * -docs, 141 * -manual (mostly JPackage)
Dunno about renaming, but based on the above, -doc could at least be a recommendation for new packages (but then again, IMVHO -docs "sounds" better ;).
Or maybe we should just make sure all of the packages have a Provides: foo-doc[s] so getting the name wrong still works (at least for apt).
Well, if adding the Provides, one could add Obsoletes and rename while at it... assuming a miracle happens and there's suddenly a consensus what they should be renamed to.
Ville Skyttä wrote:
On Sat, 2004-07-17 at 19:19, Steven Pritchard wrote:
So should those packages be renamed to whatever-doc (or *-doc be renamed to *-docs)?
FC3test1: 10 * -doc, 5 * -docs, 1 * -manual. fedora.us: 2 * -doc, 2 * -docs, 0 * -manual. rpmseek.com: 1204 * -doc, 129 * -docs, 141 * -manual (mostly JPackage)
Dunno about renaming, but based on the above, -doc could at least be a recommendation for new packages (but then again, IMVHO -docs "sounds" better ;).
I ran into this same issue in naming database fileds in tables and variables in my programming. I decided that the singular form is the preferred way to go. Because i was normally refering to a single instance of whatever the item was. In this case i believe the same rules apply. The package really contains the "documentation" not the "documentations". It seems silly but it makes sense for me and i have never had to wonder or check if my variable was "apple" or "apples". -- Michael Favia Insites Incorporated
On Sat, 17 Jul 2004 14:39:10 -0500, Michael Favia wrote:
Ville Skyttä wrote:
On Sat, 2004-07-17 at 19:19, Steven Pritchard wrote:
So should those packages be renamed to whatever-doc (or *-doc be renamed to *-docs)?
FC3test1: 10 * -doc, 5 * -docs, 1 * -manual. fedora.us: 2 * -doc, 2 * -docs, 0 * -manual. rpmseek.com: 1204 * -doc, 129 * -docs, 141 * -manual (mostly JPackage)
Dunno about renaming, but based on the above, -doc could at least be a recommendation for new packages (but then again, IMVHO -docs "sounds" better ;).
I ran into this same issue in naming database fileds in tables and variables in my programming. I decided that the singular form is the preferred way to go. Because i was normally refering to a single instance of whatever the item was. In this case i believe the same rules apply. The package really contains the "documentation" not the "documentations".
"docs" is short for "documentation files" (= ".doc files").
Steven Pritchard (steve@silug.org) said:
So should those packages be renamed to whatever-doc (or *-doc be renamed to *-docs)? Or maybe we should just make sure all of the packages have a Provides: foo-doc[s] so getting the name wrong still works (at least for apt).
Frankly, I've been of the opinion that the docs should be merged into the main package, and can be installed with --excludedocs if people want that. I'm probably in the minority though (and the PHP manual makes this excessive. :) )
Bill
Once upon a time, Bill Nottingham notting@redhat.com said:
Frankly, I've been of the opinion that the docs should be merged into the main package, and can be installed with --excludedocs if people want that. I'm probably in the minority though (and the PHP manual makes this excessive. :) )
But how do you add or remove docs after the fact?
Chris Adams (cmadams@hiwaay.net) said:
Once upon a time, Bill Nottingham notting@redhat.com said:
Frankly, I've been of the opinion that the docs should be merged into the main package, and can be installed with --excludedocs if people want that. I'm probably in the minority though (and the PHP manual makes this excessive. :) )
But how do you add or remove docs after the fact?
Well, in general, you can always remove them by hand and install newer versions with --excludedocs.
The other way is messier, though.
I just don't like a lot of packages which are 'maybe useful but no good way to get them installed in any sane automated or easily defined fashion'. Which most -doc packages are.
Bill
On lun, 2004-07-19 at 16:24 -0400, Bill Nottingham wrote:
Steven Pritchard (steve@silug.org) said:
So should those packages be renamed to whatever-doc (or *-doc be renamed to *-docs)? Or maybe we should just make sure all of the packages have a Provides: foo-doc[s] so getting the name wrong still works (at least for apt).
Frankly, I've been of the opinion that the docs should be merged into the main package, and can be installed with --excludedocs if people want that. I'm probably in the minority though (and the PHP manual makes this excessive. :) )
Sometimes docs are reference material and are quite useful even without the associated binaries (think intranet documentation server).
I feel that's what the -manual (in apache-manual and in all jpp -manual packages) intends to convey.
Though I must also say the /usr/share/doc mess is really not adapted to this usage (some packages install executable scripts in there for christsake!). A root dedicated to cleanly laid-out html manuals would be much better to export via http/ftp/nfs/cifs/whatever. That would be a perfect way to start seeding /srv/ for example.
Cheers,
Nicolas Mailhot wrote:
A root dedicated to cleanly laid-out html manuals would be much better to export via http/ftp/nfs/cifs/whatever. That would be a perfect way to start seeding /srv/ for example.
A great idea IMO. Or even better a standardized DOC format that can be filtered through httpd to produce customized manuals and documentation. I would appreciate this as well.
Michael Favia
On Mon, 2004-07-19 at 22:24, Bill Nottingham wrote:
Steven Pritchard (steve@silug.org) said:
So should those packages be renamed to whatever-doc (or *-doc be renamed to *-docs)? Or maybe we should just make sure all of the packages have a Provides: foo-doc[s] so getting the name wrong still works (at least for apt).
Frankly, I've been of the opinion that the docs should be merged into the main package, and can be installed with --excludedocs if people want that. I'm probably in the minority though (and the PHP manual makes this excessive. :) )
FWIW, I have the totally opposite opinion, i.e. any docs beyond COPYING, ChangeLog, ... goes into a subpackage and %doc becomes only a convenience macro to put the stuff into %{_docdir}/%{name}-%{version}-%{release} -- I'm not a friend of overly excessive file coloring which makes (de)installing %doc or %lang colored files after the fact a real PITA.
Nils
-
Bill Nottingham -
Chris Adams -
Mark Derricutt -
Matthias Saou -
Michael Favia -
Michael Schwendt -
Nicolas Mailhot -
Nils Philippsen -
Rex Dieter -
Steven Pritchard -
Ville Skyttä