Some thoughts on the yum tutorial

Stuart Ellis stuart at elsn.org
Wed Jul 27 00:46:02 UTC 2005


Thanks.

I've now updated the document to:

- List repositories provided by Fedora
- Use wildcard characters escaped
- Have a clearer explanation of yum clean and caches

Comments on the other points are below.


On Tue, 2005-07-26 at 11:42 +0100, Timothy Murphy wrote:

> 
> 2. I think a tutorial should concentrate on the ways
> in which an application is most often used.
> In the case of yum, I imagine 95% of the usage
> is covered by "yum update" and "yum install".
> I would have put these first - perhaps right at the beginning -
> and put other variants in later sections, eg "Package groups".

I actually structured earlier versions like this, but ended up
consolidating all the common operations into section 4 because from the
perspective of the end-user they work in basically the same way: type
command > watch metadata files download > get transaction report > do
operation.  A certain amount of explanation is required for it to make
sense, though, so the previous sections provide the context.

Package groups might be better in a separate section, I don't know.
I'll try it out tomorrow and see how that looks.

> 3. I would have started by discussing the entries in /etc/yum.repos.d/ ,
> perhaps with model entries for the 3 standard repositories.
> That would enable people to get started as quickly as possible.

Yum in FC4 has been set up so it now isn't necessary to directly work
with the contents of the configuration files at all for normal usage.
It works out of the box, using the Fedora repositories, and you can add
and remove third-party repositories by copying .repo files (or having an
application do it).

> 4. I definitely would omit the "su -c '...'" in the examples,
> and just say you have to run yum as superuser,
> perhaps once mentioning sudo and "su -c".

It does look inelegant.  The idea is that you can dive into the document
at any point and get a command that works with no further explanation. 

My view is that sudo should be configured by anaconda to start with :)

> 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.

> 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.

> 9. I would have suggested adding non-standard repositories
> to /etc/yum.repos.d/ with enabled=0
> using yum with enablerepo=... when desired.

This involves editing the configuration files, and I don't think that you get much benefit from it, to be honest.

> 10. I think yum GPG keys cause more confusion than you realise.
> I would have mentioned the possibility of turning off key-checking
> in case one cannot find the key -
> of course as a second-best solution.

Further to what Paul has said, this issue came up on the yum mailing
list last week.  The yum developers take a strong line on unsigned
pacakges, and won't add features to make it easy for users to install
them.

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.

-- 

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/cf80ee8f/attachment.bin 


More information about the docs mailing list