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 mean...;-) rgb > jc > > > > -----Original Message----- > > From: seth vidal [mailto:skvidal@xxxxxxxxxxxx] > > Sent: Friday, May 23, 2003 7:21 AM > > To: Troy Dawson > > Cc: yum@xxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxx > > https://lists.dulug.duke.edu/mailman/listinfo/yum > > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum > -- 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@xxxxxxxxxxxx
