Some thoughts on the yum tutorial

[Stuart Ellis]

On Wed, 2005-07-27 at 08:06 -0400, Paul W. Frields wrote:

> > > 7. I think a brief description of how yum works -
> > > eg what is meant by "metadata" and where it is stored -
> > > would be useful.
> > > I'd add a few words about rmp headers as well.
> > 
> > The term headers was explained in a previous version, I think, and
> > I'll try to work it back in without too much exposition.
> 
> Let's be careful not to dump too much technical information into a
> procedural guide.  This is precisely where a lot of documentation I see
> on the web goes wrong -- it becomes what I call a "core dump" which has
> limited additional use.  When I started teaching Linux many years ago, I
> had to conquer the innate geek need to explain all the technical
> minutiae, simply because of how gosh-darned cool it all is.  (And free!
> Did I mention free?)  

Yum is definitely darn cool :).  The term header file is exposed in a
couple of places, so something like the phrase "yum downloads a data
file, or header, for each package".  I don't really want to discuss
metadata in any more depth than that here, because it is intended as a
document for users rather than developers.

> > > 8. A few words on what to do about yum errors
> > > would be very useful, perhaps as a FAQ.
> > 
> > Hmm. Could you give an example of a specific yum error ?  I would think
> > that the most common problems are likely to be general network errors.

To clarify this - with the default configuration and the default
repositories yum should work without incident.  It gets less certain if
you customize the configuration, use development versions of yum, or get
interesting RPMs from vendors...

One kind of issue that I've seen pop up on the yum list which is
definitely relevant to Fedora users with a standard setup is dealing
with proxies, so I put in section 10 to address this.  If you have other
connectivity issues then those will temporarily kill yum dead as well.

Section 7.3 was written with the current situation of third-party
repositories overlapping with Extras in mind, but it is rather vaguely
worded.  I've now altered it - hopefully it will help make things
clearer.

> > Some proprietary vendors do supply their products as individual unsigned
> > packages.  For these cases, I'm not sure whether or not we should
> > document: 
> > 
> > rpm -ivh the-vendor-is-an-idiot.1.i386.rpm
> > 
> > Purely as a courtesy to Fedora users.  I'm open to persuasion either
> > way.
> 
> My vote's against it.  It's a very short hop for the uneducated to go
> from this to "rpm -ivh --force," or worse, "rpm -e --nodeps".

Ugh.

> Beyond which, I don't want to take a single step in the direction of how
> to deal with proprietary vendors.  That's the best way to avoid a
> slippery slope argument on why we don't document use of other non-free
> software.

Yes, we don't want to go there, either.

-- 

Stuart Ellis

stuart at elsn.org

Fedora Documentation Project: http://fedora.redhat.com/projects/docs/

GPG key ID: 7098ABEA
GPG key fingerprint: 68B0 E291 FB19 C845 E60E  9569 292E E365 7098 ABEA 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20050727/8495499c/attachment.bin