Robert G. Brown
rgb at phy.duke.edu
Fri May 23 18:18:22 UTC 2003
On Fri, 23 May 2003, Carroll, Jim P [Contractor] wrote:
> And having more than one man page isn't all that bad. One merely
> needs to refer to the SEE ALSO section.
> Although it's an extreme example, I refer to the man pages for Perl.
> Would anyone really want to make that One Big Man Page?
Interesting example, though. There are issues of scale and grouping at
play here. Would you like to have to search THROUGH the man pages for
perl for commands all mixed together in a jumble, or sorted
alphabetically, especially if you were trying to learn perl from the man
pages? Would you like to try to learn perl from the man pages?
I think not. The perl man pages work at all because of tight grouping
of the topics covered, and it is not, really all that great a resource
for "learning" perl -- people learn perl from other resources such as
the many excellent O'Reilly books on Perl, and the man pages are just a
way to get a quick reminder on particular questions of syntax.
I'd continue to argue that yum is only big enough to justify (at most)
two separate executables, and that the executable split should be along
functional root/user or maintenance/information lines (they are pretty
much the same).
Yum is also more than big enough for the next step in its documentation
evolution -- the yum HOWTO, on tldp.org and everything. Zouhir's
composite HOWTO doesn't appear (from google) to have made the big time
onto tldp.org, and this is a problem. As list traffic here testifies,
although yum is "simple" (especially from the user/client end) it is
complex enough to need a real book-form manual, and not just a man page.
Setting up a repository collection step by step, building yum rpm's for
local clients that will automagically update from the repository they
come from, how to use the various yum informational commands to get the
most juice from the repository, True Evil Facts about rpm's, dependency
loops, and other things you never really wanted to know, perhaps a
crossreference section outlining "good practice" for rpm builders so
that the rpms they build will work well in yum managed (and other rpm)
repositories, and even a section on bugs and what to do about them.
Yup, more than enough for a fairly involved howto if not a small book.
Seth, I haven't contributed much to the project besides a lot of sheer
blissful vibes radiating back to you every time I use the tool. I've
written at least one short HOWTO and therefore have worked through the
SGML template. You want me to tackle a howto as a contribution, or
would you or Michael prefer to write it? You certainly know more (and
will have to check what I write and whomp me upside the head when it
comes out stupid) but I probably type faster. Than anybody, I
> > -----Original Message-----
> > From: seth vidal [mailto:skvidal at phy.duke.edu]
> > Sent: Friday, May 23, 2003 7:21 AM
> > To: Troy Dawson
> > Cc: yum at linux.duke.edu
> > Subject: Re: [Yum] yum-tool
> > On Thu, 2003-05-22 at 09:01, Troy Dawson wrote:
> > > Hi Seth,
> > > I think it's a good idea. My only hesitation is that you
> > leave the ones that
> > > are currently in yum, in yum. Though they could be
> > parralled in yum-tool.
> > >
> > > I also like the idea of just one name with different
> > options (yum-tool versus
> > > yum-search, yum-checkheaders, etc...). That way people
> > only have to remember
> > > one main command, and only one man page to look at. The
> > phrase RTFMP just
> > > doesn't apply if you can't figure out which man page to read.
> > >
> > but this is just like:
> > redhat-config[tab][tab]
> > :)
> > -sv
> > _______________________________________________
> > Yum mailing list
> > Yum at lists.dulug.duke.edu
> > https://lists.dulug.duke.edu/mailman/listinfo/yum
> Yum mailing list
> Yum at lists.dulug.duke.edu
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu
More information about the Yum