On Thu, 23 Oct 2003, Robert P. J. Day wrote: > (as an analogy, if someone knew nothing about, say, DNS, it seems natural > to first explain how it works at the client level, *then* go on to server > configuration. my point is simply that, to make yum accessible, complete > newbies *need* to be told how to start using it. once they're > comfortable, they can make the decision as to whether they want to go > further and create their own repositories.) It's a good analogy. Nobody non-unix-expert can use DNS as a user unless their system is preconfigured to use it by an expert, and then nobody even knows that their system is using it. DNS documentation thus focuses almost entirely on setting up DNS at the administrative level in ALL books and references, or using programming interface tools (e.g. gethostbyname()) that are quite complicated in and of themselves and that presuppose nameservice is already configured to automagically work. Even client tools like "host" or "dig" or "nslookup" (deprecated) are unknown to nearly all users, who know of nameservice at all only by its failure. Yum even as a client tool is nearly all privileged; you can break the hell out of your system without really trying, there are significant security considerations (you are what you eat, so to speak, and your system is thus no more secure than your public repository), and unlike nameservice there IS no central authority, central/public repository or repository redirection system that balances load, or manages things like host authentication of the repositories selected. For all of these reasons, yum as a purely userspace, plug-n-play client tool in the hands or Unix novices scares the hell out of me (and, I suspect, Seth and Michael). It just isn't there yet, not by a long shot. To complete the metaphor, nameservice only "works" for novice users because of e.g. DHCP. At this point an entire public infrastructure would need to exist, along with tools LIKE dhcp (some sort of "repository server") for yum to really be ready for userspace prime time unsupported by a systems admin and a local repository, where a novice user could just install yum from a generic distribution rpm (unmodified by any local sysadmin) on their system and have it "just work" from a chain of perfectly revision-matched public repositories. Sure this works NOW, for a handful of independent users and due to some generosity on the part of some repository maintainers, but it won't work in the indefinite future because the current model does not scale to infinity and beyond. Nameservice (which serves our far less data, per call) wouldn't work if every lookup had to go back to one centralized nameserver... > just FYI, i'm putting together a yum intro that will become part of a RH > admin courseware manual, and one of the first things i'm going to do is > explain the files/directories that come with yum. IMHO, there's nothing > that sets the stage better than making sure someone understands all the > parts of a package and what they're for, as in: > > /usr/bin/ > yum > yum-arch > /var/cache/yum/ > > /etc/yum.conf > /etc/init.d/yum > /etc/logrotate.d/yum > /etc/cron.daily/yum.cron > > /usr/share/yum/ > /usr/share/doc/yum-* > > the way my manual is structured, by the time we hit the chapter on SW > management, students will have already covered: > > - logging and log files > - cron and task scheduling > - service management and /etc/init.d > > so none of the above will come as a shock and it should all make perfect > sense. and it gives folks an instant picture of all the parts and how > they hang together. at that point, i start with how to use "yum" at the > client level, and so on. > > anyway, just my $0.03 cdn. if i were a beginner, i just want a quick > overview to the package, then just start showing me how to use it, that's > all. If you write it such an overview in linuxdoc, I will cheerily add it to the existing HOWTO. I will also buy you a beer should by chance we ever meet (or send you funds sufficient for the beer of your choice via paypal, with the same true for JP:-) and add you to the authors list. There is a howto project template here: http://www.phy.duke.edu/~rgb/General/project.howto.php that should let you see the syntax/documentation for linuxdoc and even preview a result. In fact, I'd recommend that you use linuxdoc (or some sort of tldp sgml) as the manual basis anyway. I'll cheerfully send you the entire sources of the howto if you want to use it as a basis; it is all GPL'd in the appropriate venue. (BTW the project template still has bugs in the makefile, sorry). rgb -- 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
