On Thu, 23 Oct 2003, Robert P. J. Day wrote:
>
> i noticed, in rgb's new draft, updated terminology for the terms
> "server" and "repository", which seems to be more in line with what most
> folks would assume:
>
> server: a physical system (which could, of course, contain multiple
> independent repositories)
> repository: a yum-arch'ed collection of RPMs -- essentially, a directory
> reference
>
> but the next term, "serverid", seems out of place. from what i read, it
> defines a possibly redundant set of repositories that are meant to
> mirror/backup one another. would it not be more appropriate to refer to
> this as a "repositoryid"? since it seems that a single (physical) server
> might contain more than one of these *sets* of repositories, right?
>
> or did i misread this?
>
> rday,
>
> p.s. i'm assuming that what we're talking about in terms of a
> "serverid"/"repositoryid" is a label that would say something like "fedora
> core 1.0", which would completely identify the version of the RPMs
> contained therein, right?
I've avoided commenting on this lovely thread so far, as I'm waiting for
the survey to complete and all comments to register without my
interference before chiming in. This particular one I'll address, as it
is something I don't disagree with, but requires coordinated action to
change. "serverid" is the term used in man yum.conf. It >>is<< just a
label, and it >>does<< refer to a deliberately redundant set of
repositories. I don't want the HOWTO to be jarringly out of sync with
the actual documentation, so I've left this, but would cheerfully change
it if Seth changes the man references to match.
Oh, hell, might as well address the rest of the comments and overall
issue now as well. The list is likely biased in favor of administrators
for obvious reasons (as Seth observed) and this clearly comes through in
the applications survey so far. Only one person (IIRC) replied that
they "just" used yum as a client using public repositories and were
interested in going no further. Everybody else either has repositories
of their own or would like to. I also use yum servers even at home, and
think that many users of yum even at the single machine level will
likely want to set up a filesystem based yum repository as it makes it
MUCH easier to shop their distribution CD set for interesting packages,
for example. This has been my (possibly biased as noted) motivation for
focusing on server setup before client.
I'd further argue that as a client, yum is pretty well documented in its
man pages already; that's why I've blown off actually finishing the
yum-client documentation in the howto so far (excuses excuses, although
I am GOING to document its client function in the HOWTO as well and
might even have the time to put in another block of writing/editing Real
Soon Now:-). In fact, for a lot of purposes just running the bare "yum"
command without an option gives you enough of a prompt to get started,
although admittedly not if you are a complete unix/linux novice.
If/when somebody actually finishes a Gtk encapsulation of yum in a GUI
with buttons and a Help entry and the little popup that encourages a
user to enter the root password to enable root-privileged sub-commands,
even the man pages won't be necessary to most users.
The server/repository side, however, is the tricky part, in terms of
writing a yum.conf, running yum-arch, providing a URI access medium.
For example, I recently (offline) helped somebody debug a filesystem
based yum.conf, which I hadn't personally tried yet. Both of us
(arguably foolishly) tried a URI like "file://path/to/repository" (on an
NFS mount, actually). Fortunately discussion on the list incidentally
made it clear that the right syntax is "file:///path/to/repository" --
"obviously" the leading "/" is significant as otherwise it probably
looks in e.g. ~root and returns a file not found error. Stuff like this
doesn't "have" to be documented as sure, after the fact it makes sense
to the experienced, but it is also an easy mistake to make EVEN for the
experienced as http and ftp URI paths start with a default head/root
path and no extra "/".
Then there are the details of setting up a public repository for http,
for ftp, on a filesystem, from a CDROM (where I haven't tried it but
assume that one has to create a CDROM mount point one directory down
from a repository head so that yum-arch can do its thing in the
writeable part of the repository while the actual RPM repository is RO).
One cannot document ALL of this (some of these have HOWTOs of their
own:-) but it is a lot easier to get a minimal boost in context. JP (my
co-author) has been very helpful in this regard, adding fairly explicit
instructions for setting up an ftp repository; eventually I'll detail an
http and nfs (filesystem) based repository and warn of gotchas like
these.
Finally there is the issue of the HOWTO design. There is actually a
HOWTO style guide on tldp.org, and I'm trying to at least roughly follow
it. Possibly badly, of course:-). In it you're supposed to present an
overview for novices, followed by detail sufficient to bridge the gap
between novice and competent user, if not total expert. The man pages
(and for purists, sources:-) remain THE actual hard technical
documentation especially for a product being rapid developed, but the
HOWTO should be general enough and up to date enough to get somebody
going even if features have been added or minimally changed since the
last HOWTO update. Obviously it is much easier to maintain the HOWTO
when the period of major feature creep is over;-)
With all that said, it is very reasonable to consider moving the
yum-client documentation (once I've actually written it:-) ahead of the
server setup documentation, OR to add a very direct section to the
abstract/intro directing a reader of the HOWTO to the correct section in
whatever order it appears. I was planning to add an "overview" section
either before the introduction or as the first section of the
introduction where this is done -- a sort of "read this if you don't
want to read the whole HOWTO" section that many howtos have. This
section might actually have a handful of "out of the box" examples of
the use of yum (presuming the client is packaged so that it WORKS out of
the box, that is, predirected to a public yummified repository).
It is this last issue that is a bit sticky. Where in the world could
there be a repository that could withstand the pressure produced by yum
as a mainstream client installed on e.g. all RH systems? Seth is a nice
guy, the dulug/linux@duke mirrors can handle a decent amount of offsite
traffic, but add a few hundred thousand users with nightly cron jobs
trying to update from this site and it will likely bring the server to
its knees. As I see it in the not terribly distant future the ONLY way
yum will likely work is from a "local" repository, unless somebody funds
and maintains a high-bandwidth multihomed server just for public
yumsumption. RH can afford to do this (easily) out of the incredibly
high prices they appear to be seeking to charge for RHEL (another story
that is very deserving of an rgb rant at some future date:-).
Perhaps we could talk ibiblio into doing so -- they have public money
and a fat pipe and are physically close by to Duke. I don't think the
dulug server(s) will stand it unless we e.g. seek a public grant and get
perhaps a few $100K/year for building a real server farm, paying for a
slice of Duke's bandwidth, and defraying the human maintenance costs
(a.k.a. getting a human who can help Seth out).
Otherwise, what the current layout of mirrors etc. likely WILL stand is
people building lots of local public rsync mirrors in a tree. By its
nature, such a tree distributes the load over many sites, and of course
this is the model used by lots of major distribution systems e.g.
sourceforge. This in fact COULD be an alternative to a grant and
localized server farm -- create a set of linked public mirrors and a
master site that uses yum itself to distribute e.g. yum.conf's
preconfigured to use a "local", load balanced, public mirror.
Until this sort of thing exists, I tend to think the HOWTO should focus
more on server setup (putting this first) and be more for administrators
than users per se. However, I will cheerily bow before the will'o'the
list, if y'all want to vote.
Regarding the lack of a link to the HOWTO on the main yum site; this is
mostly a matter of the HOWTO still not being really "done". It is a
draft -- probably in an "alpha" stage where y'all are early adopters if
you read it at all:-) -- and won't be in a "beta" stage until I actually
finish the yum client section and probably rewrite the intro/overview
section accordingly. At some point in there we can both put or link a
copy to the main yum page easily enough, and shortly thereafter I'll
submit the howto to tldp.org in any event so it functions more to funnel
people back to the yum site than the other way around.
At that point I'd also recommend registering yum.org and pointing it
directly at the yum site. This makes the URI in the documentation
independent of the actual hosting server (redirectable via nameservice
changes), which means the documentation won't need to be updated if it
is ever physically moved from server to server. It is also where people
will "naturally" look for a yum site. If dulug doesn't have money to
pay for the registration, I'll donate it personally for at least a few
years. In fact, I'd recommend doing this at THIS point -- there is no
reason to wait on me and the HOWTO...
rgb
>
> _______________________________________________
> 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
