Some thoughts on the yum tutorial

[Timothy Murphy]

===========================================
I thought the yum tutorial was pretty good -
I'd give it 8/10 .
The following remarks are meant as comments rather than criticism.

0. I found the general approach slightly over-formal
even perhaps a tiny bit unfriendly.
But that is just a personal view.

I would have put the "Revision history" as a link,
perhaps just leaving the date of the latest revision,
and the author or authors.

1. As far as I can see, there are three standard fedora yum repositories:
fedora base (covering the rpms on the distribution CDs),
fedora update and fedora extras.

If that is correct, I suggest it should be said clearly,
as postings suggest some confusion over this.

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

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.

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

5. In case people are using sudo or su,
perhaps it should be mentioned that eg * should be given as \*
in yum search, etc.

6. When discussing "yum clean" it should be explained
what disadvantages if any this may have.
You say that cached rpms "may be re-used";
what exactly does this mean?

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.

8. A few words on what to do about yum errors
would be very useful, perhaps as a FAQ.

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

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

-- 
Timothy Murphy  
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: [phone]
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland

[Ignacio Vazquez-Abrams]

On Tue, 2005-07-26 at 11:42 +0100, Timothy Murphy wrote:
>  5. In case people are using sudo or su,
>  perhaps it should be mentioned that eg * should be given as \*
>  in yum search, etc. 
No, wildcards should *always* be escaped.

-- 
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72

[Paul W. Frields]

Thanks for your comments, Timothy, they are appreciated.  I'll let
Stuart address the content part of this, but:

On Tue, 2005-07-26 at 11:42 +0100, Timothy Murphy wrote:
>  0. I found the general approach slightly over-formal
>  even perhaps a tiny bit unfriendly.
>  But that is just a personal view. 
Official FDP material is, by nature, a bit more formal than what a lot
of readers are used to seeing from third-party sites or venues like
FedoraNews.  We have fairly comprehensive style guidelines, and try to
adhere to them whenever possible.  Doing so reduces translation
problems, adds to reader comprehension, and increases consistency in our
documentation process.  My personal predilection is for our work to look
a lot like the language used in the old Red Hat Linux documentation,
which is definitely a bit more formal, but easy to read, understand, and
translate to other languages.

>  I would have put the "Revision history" as a link,
>  perhaps just leaving the date of the latest revision,
>  and the author or authors. 
This is generated as part of our current DocBook stylesheets, but maybe
there's a way to make it come out as part of an appendix instead.  Does
anyone have any clues about this?

>  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. 
I would not recommend that, nor do I think would any of our
security-conscious writers.  :-)  GPG signatures on your packages ensure
that you are not receiving tampered copies.  Turning off GPG key
checking increases your system's vulnerability, and is not a good idea.
If you can find us some information on common yum/GPG problems, it might
be possible to write some of that into a troubleshooting section.  But
as an official documentation group, we should be *extremely* cautious
about telling anyone to decrease their security measures.

Your other suggestions may have a good deal of merit; I'll leave it to
Stuart as the author to consider them and post his thoughts.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/

[Stuart Ellis]

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(a)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

[Timothy Murphy]

Stuart Ellis wrote:

> > 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). 
I always replace the repositories given in the default entries
by local repositories (I mean in Ireland, in my case).
I don't know if that is standard practice.

> > 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. 
I don't think so.
I think it is clear from postings to the general Fedora mailing list
that by far the most common problem is dependencies that cannot be resolved.

These generally seem to be due to an injudicious choice of repositories.

You are the yum experts, but my advice in such a case would be
that if "yum update" is failing and there is just one problematic package
one should add "exclude=..." to yum.conf, at least temporarily.

The other problem that comes up pretty often is to do with GPG keys.

> > 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. 
That's fine.
But if they feel strongly about it
they should add something to the yum error messages
to suggest where users might find missing keys.

Incidentally, since the keys seem to be put in /etc and/or /usr/share/doc
I don't know why installing yum doesn't install these keys at least.


I was slightly perturbed by your belief
that most yum difficulties arise from network problems
since this certainly is not the case from my reading of postings on yum.

I think every tutorial should have a FAQ section;
and it is important that the FAQs should be questions
that actually arise.
All too often FAQs are used, in my view,
for authors to add material they want to add
rather than answering questions people are really likely to ask.

-- 
Timothy Murphy  
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: [phone]
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland

[Paul W. Frields]

On Wed, 2005-07-27 at 01:46 +0100, Stuart Ellis wrote:
>  > 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 :) 
Better yet, why isn't it just tied to consolehelper like other superuser
programs?  After all, there's not much you can do with yum that's really
useful unless you've got that level of access.  Then there would be no
sudo required.  I suspect this was a bit of a compromise on Seth's part.
I suppose in the future it might be possible for something like a
yum-generated dbus message that would alert the system you need
superuser access, so it could generate a consolehelper-type prompt.

>  > 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?)  

This tutorial does not need to explain, for example, the RPM format to
teach people how to manage software on their systems.  Keep the mission
in mind at all times.  Unless information actually helps someone get the
job done, it's superfluous.  That being said, certain concepts are
irrevocably tied to understanding a procedure.  Those should remain in
the docs.

>  > 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. 
Good point, see above!

>  > 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. 
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". 
("Hey,
why should I bother with yum? It puts all that crap on my screen.")
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.  Let me get off my soapbox before I take that too far,
sorry.  :-)

As part of the official Voice of Fedora (sorry, getting geared up for
that "V for Vendetta" movie), we should probably toe the party line on
this one.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/

[Paul W. Frields]

On Wed, 2005-07-27 at 11:58 +0100, Timothy Murphy wrote:
>  Stuart Ellis wrote:
>  
>  >> 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).
>  
>  I always replace the repositories given in the default entries
>  by local repositories (I mean in Ireland, in my case).
>  I don't know if that is standard practice. 
It's not, since the default entries are to mirror lists and not single
sites.  Your package requests go to a random mirror entry, meaning
there's a basic and large-scale load balancing that happens without you
having to do anything.  What happens otherwise if your local repo is
down?

>  >> 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.
>  
>  I don't think so.
>  I think it is clear from postings to the general Fedora mailing list
>  that by far the most common problem is dependencies that cannot be resolved.
>  
>  These generally seem to be due to an injudicious choice of repositories. 
That never seems to happen with Fedora Core and Extras, as far as I'm
aware -- or at least it never has happened to me, and I download random
stuff sometimes just to see what happens. :-)  Since Core and Extras are
all we document, anything else is outside our scope.

>  You are the yum experts, but my advice in such a case would be
>  that if "yum update" is failing and there is just one problematic package
>  one should add "exclude=..." to yum.conf, at least temporarily. 
Actually, we're not yum experts, we just try our best.  On good days, we
pretend to be documentation experts. ;-)  Hopefully the real yum experts
are looking at the docs and also making suggestions.

>  The other problem that comes up pretty often is to do with GPG keys.
>  
>  >> 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.
>  
>  That's fine.
>  But if they feel strongly about it
>  they should add something to the yum error messages
>  to suggest where users might find missing keys.
>  
>  Incidentally, since the keys seem to be put in /etc and/or /usr/share/doc
>  I don't know why installing yum doesn't install these keys at least. 
It does, the first time you use each repository.  (I'm speaking for FC4;
I don't know the status of yum in FC2 or 3 right now.)  The only keys
included are for official Fedora repositories, for obvious reasons.
Those keys are now kept in /etc/pki/rpm-gpg/ in FC4.  If you pick up
a .repo file from some other place, the author of that file (probably
the repository owner) should have a URL for their repo's GPG key in that
file.  If they do, yum asks you if you want to import that key.  If the
repo owner doesn't sign a package, or signs it wrong, yum can't fix
that.

Again, Core and Extras are always built and signed by the Fedora build
systems (mostly automated now), so this tends not to happen there.
Other repos probably do similar things, but the Fedora Project doesn't
have any say in what they do.

>  I was slightly perturbed by your belief
>  that most yum difficulties arise from network problems
>  since this certainly is not the case from my reading of postings on yum. 
Please don't be perturbed, it was just Stuart's opinion.  Opinions can
be uninformed; that's why we have discussions.  I don't know either way.

>  I think every tutorial should have a FAQ section;
>  and it is important that the FAQs should be questions
>  that actually arise.
>  All too often FAQs are used, in my view,
>  for authors to add material they want to add
>  rather than answering questions people are really likely to ask. 
I don't think every tutorial should have a FAQ section.  But I do agree
that user questions that the tutorial doesn't answer -- *and* which are
in the scope of the tutorial and this project as a whole -- should be
fixed in the tutorial.  That's why Fedora Documentation now has its own
product category on Bugzilla.  If you have a question that doesn't get
answered in a document that we publish, you can file a bug against it,
just like with a piece of software that doesn't work the way you like.
We are really excited that we will be able to track this kind of work
with the same tools and precision used by the Fedora software
developers.  I hope you'll take advantage of it.

In the meantime, I look forward to hearing your take on the issues I
raise above.  Thanks for your continued input, since it is very helpful
to us.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/

[Yoshihiro Totaka]

Paul W. Frields wrote:
>  On Wed, 2005-07-27 at 11:58 +0100, Timothy Murphy wrote:
>  
> >Stuart Ellis wrote:
> >
> >
> >>>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).
> >
> >I always replace the repositories given in the default entries
> >by local repositories (I mean in Ireland, in my case).
> >I don't know if that is standard practice.
>  
>  
>  It's not, since the default entries are to mirror lists and not single
>  sites.  Your package requests go to a random mirror entry, meaning
>  there's a basic and large-scale load balancing that happens without you
>  having to do anything.  What happens otherwise if your local repo is
>  down?
>   
There is a country mirror list and simply adding country code to default 
mirror list works. I am living in Japan and using default mirror list is 
unbearably slow. So I am using following following mirror lists.
http://fedora.redhat.com/download/mirrors/fedora-core-$releasever.jp
Mentioning of these country mirror list would be nice.
(I am not saying everyone should use it.)

<snipped>


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.5/58 - Release Date: 2005/07/25

[Paul W. Frields]

On Wed, 2005-07-27 at 22:34 +0900, Yoshihiro Totaka wrote:
>  Paul W. Frields wrote:
>  > On Wed, 2005-07-27 at 11:58 +0100, Timothy Murphy wrote:
>  > 
>  >>Stuart Ellis wrote:
>  >>
>  >>
>  >>>>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).
>  >>
>  >>I always replace the repositories given in the default entries
>  >>by local repositories (I mean in Ireland, in my case).
>  >>I don't know if that is standard practice.
>  > 
>  > 
>  > It's not, since the default entries are to mirror lists and not single
>  > sites.  Your package requests go to a random mirror entry, meaning
>  > there's a basic and large-scale load balancing that happens without you
>  > having to do anything.  What happens otherwise if your local repo is
>  > down?
>  > 
>  
>  There is a country mirror list and simply adding country code to default 
>  mirror list works. I am living in Japan and using default mirror list is 
>  unbearably slow. So I am using following following mirror lists.
>  http://fedora.redhat.com/download/mirrors/fedora-core-$releasever.jp
>  Mentioning of these country mirror list would be nice.
>  (I am not saying everyone should use it.) 
This is not a bad idea, but I notice that in quite a few cases, the
country-specific mirrors are only one server.  Since intracontinental
bandwidth is generally good (right?), this may not be strictly
necessary.  Of course, if you don't use it at all, chances are pretty
good that quite a bit of EMEA traffic will end up coming to the US.  My
understanding is that's still undesirable.  Anybody know differently?

For what it's worth, I usually add the .us.east to the end of mine, as
well.  Perhaps it's worth filing a bug against firstboot to see if the
developers can incorporate a way to feed the country mirror list to the
user for selection?

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/

[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(a)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

Some thoughts on the yum tutorial -- one example : galeon

[Beartooth]

On Wed, 27 Jul 2005 11:58:32 +0100, Timothy Murphy wrote:

>  Stuart Ellis wrote:
>  
> >> 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.
>  
>  I don't think so.
>  I think it is clear from postings to the general Fedora mailing list
>  that by far the most common problem is dependencies that cannot be
>  resolved.
>  
>  These generally seem to be due to an injudicious choice of repositories.
>  
>  You are the yum experts, but my advice in such a case would be that if
>  "yum update" is failing and there is just one problematic package one
>  should add "exclude=..." to yum.conf, at least temporarily. 
[....]
>  I was slightly perturbed by your belief that most yum difficulties
> arise
>  from network problems since this certainly is not the case from my
>  reading of postings on yum. 
I'm just a thoroughly subtechnoid user, and I mean every syllable of my
.sig motto; so I can't speak to the actual issue. But I do have an example
you might could use.

When I first installed FC4 and had run yum update, I ran yum install
galeon, on the faint chance it might eventually work some day. (I gave up
galeon -- then my favorite browser -- years ago, when its dependency hell
with mozilla got too much for me. I've kept mozilla, which I detest, ever
since on the same faint hope.)

Much to my delight and amazement, it worked. Galeon runs -- on that one
machine.

A few days later, when I tried it again on other newer FC4 installs (on
older machines), I got dependency hell again. And still do. Such galeon
developers as have responded to my post on 7/23 to
gmane.comp.web.galeon.user (titled Dependency hell *again*) don't seem to
think there's anything they can and want to do.

As I said there, I have no idea whether this is a yum problem, a repo
problem, or something still different. (They seem to be saying it's not
a galeon problem.) But if it's not a galeon problem, it *looks* like one
of those two (if they're really different) to such uninformed users as
myself -- and likely gets called one on lists ...

Maybe someone here can at least tell why this trouble is chronic with
galeon/yum, and yet not with epiphany nor firefox. (I've never encountered
it with either, and have been using both for years.)

-- 
Beartooth Senectoflatuloid, Neo-Redneck, Linux Convert
Remember, I have precious little idea what I am talking about.

[Karsten Wade]

On Wed, 2005-07-27 at 08:21 -0400, Paul W. Frields wrote:
>  On Wed, 2005-07-27 at 11:58 +0100, Timothy Murphy wrote:
>  > 
>  > I always replace the repositories given in the default entries
>  > by local repositories (I mean in Ireland, in my case).
>  > I don't know if that is standard practice.
>  
>  It's not, since the default entries are to mirror lists and not single
>  sites.  Your package requests go to a random mirror entry, meaning
>  there's a basic and large-scale load balancing that happens without you
>  having to do anything.  What happens otherwise if your local repo is
>  down? 
I wonder if the idea of having repositories package their .repo and
other files in an RPM is going to take hold?  As long as the Core and
Extras repositories do that, we can use them as an example in such a way
that users understand they can do the same with a repo package from
their favorite outside repository.

Keeping our focus on *only* what ships in Core and Extras makes our jobs
both easier and hard.  The old rule that, "When the only tool you have
is a hammer, suddenly every problem looks like a nail," that can happen
to us.  However, it is awfully nice to have a scope.

This is my way of saying that I concur with Paul's assessment about
discussing with outside repositories.  

One way to be helpful could be, if we had an FAQ with a question that
would have an answer of, "Don't cross the repository streams," we can
just tell people that if they are using non-Core or Extras repositories,
they may have conflicts between packages in those files, yadda yadda
yadda.

- Karsten
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
                       Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

[Stuart Ellis]

On Wed, 2005-07-27 at 13:42 -0700, Karsten Wade wrote:

>  One way to be helpful could be, if we had an FAQ with a question
> that
>  would have an answer of, "Don't cross the repository streams," we can
>  just tell people that if they are using non-Core or Extras repositories,
>  they may have conflicts between packages in those files, yadda yadda
>  yadda. 
I've just committed to CVS an amended section on "Understanding
Repository Compatibility" (sn-compat-repositories), with some stuff on
third-party repository compatibility. Hopefully that will help encourage
people to be careful with repository mixing.

-- 

Stuart Ellis

stuart(a)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

[Karsten Wade]

On Wed, 2005-07-27 at 22:42 +0100, Stuart Ellis wrote:
>  On Wed, 2005-07-27 at 13:42 -0700, Karsten Wade wrote:
>  
>  > One way to be helpful could be, if we had an FAQ with a question that
>  > would have an answer of, "Don't cross the repository streams," we can
>  > just tell people that if they are using non-Core or Extras repositories,
>  > they may have conflicts between packages in those files, yadda yadda
>  > yadda.
>  
>  I've just committed to CVS an amended section on "Understanding
>  Repository Compatibility" (sn-compat-repositories), with some stuff on
>  third-party repository compatibility. Hopefully that will help encourage
>  people to be careful with repository mixing. 
I updated the beta, should be live within the hour at:

http://fedora.redhat.com/docs/beta/yum-software-management/

-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
                       Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

[Paul W. Frields]

On Wed, 2005-07-27 at 13:42 -0700, Karsten Wade wrote:
>  On Wed, 2005-07-27 at 08:21 -0400, Paul W. Frields wrote:
>  > On Wed, 2005-07-27 at 11:58 +0100, Timothy Murphy wrote:
>  > > 
>  > > I always replace the repositories given in the default entries
>  > > by local repositories (I mean in Ireland, in my case).
>  > > I don't know if that is standard practice.
>  > 
>  > It's not, since the default entries are to mirror lists and not single
>  > sites.  Your package requests go to a random mirror entry, meaning
>  > there's a basic and large-scale load balancing that happens without you
>  > having to do anything.  What happens otherwise if your local repo is
>  > down?
>  
>  I wonder if the idea of having repositories package their .repo and
>  other files in an RPM is going to take hold?  As long as the Core and
>  Extras repositories do that, we can use them as an example in such a way
>  that users understand they can do the same with a repo package from
>  their favorite outside repository.
>  
>  Keeping our focus on *only* what ships in Core and Extras makes our jobs
>  both easier and hard.  The old rule that, "When the only tool you have
>  is a hammer, suddenly every problem looks like a nail," that can happen
>  to us.  However, it is awfully nice to have a scope. 
Strangely, the other day I was thinking about another cautionary axiom
for the FOSS world, which is "Even if you just discovered a toolbox full
of fizzgigs, hoojybodgies and whatsits, sometimes the nail pops need to
be addressed first.  Use the hammer for that."  I hope that my admitting
this isn't somehow undermining your point; I just had to get it off my
chest.

>  This is my way of saying that I concur with Paul's assessment
> about
>  discussing with outside repositories.  
>  
>  One way to be helpful could be, if we had an FAQ with a question that
>  would have an answer of, "Don't cross the repository streams," we can
>  just tell people that if they are using non-Core or Extras repositories,
>  they may have conflicts between packages in those files, yadda yadda
>  yadda. 
Since Extras became fully open to community participation, there's a lot
fewer problems with repository conflicts.  Most of the third-party repos
have tended to drop things that are appearing in Extras, meaning that
most conflicts occur between different third-party repos.  A few of them
are consolidating to address the problem.  Some claim there is no
problem.  Some are correct.  

Since so many of them are offering legally encumbered solutions, it's a
touchy situation for us to address.  Telling people "don't cross the
repo streams" (I like this one!) may not be as accurate as "don't cross
*certain* repo streams," but we need to stay out of that morass AFAIC.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/

Some thoughts on the yum tutorial -- one example : galeon

[Paul W. Frields]

On Wed, 2005-07-27 at 16:25 -0400, Beartooth SenectoFlatuloid wrote:
[...snip...]
>  When I first installed FC4 and had run yum update, I ran yum install
>  galeon, on the faint chance it might eventually work some day. (I gave up
>  galeon -- then my favorite browser -- years ago, when its dependency hell
>  with mozilla got too much for me. I've kept mozilla, which I detest, ever
>  since on the same faint hope.)
>  
>  Much to my delight and amazement, it worked. Galeon runs -- on that one
>  machine.
>  
>  A few days later, when I tried it again on other newer FC4 installs (on
>  older machines), I got dependency hell again. And still do. Such galeon
>  developers as have responded to my post on 7/23 to
>  gmane.comp.web.galeon.user (titled Dependency hell *again*) don't seem to
>  think there's anything they can and want to do.
>  
>  As I said there, I have no idea whether this is a yum problem, a repo
>  problem, or something still different. (They seem to be saying it's not
>  a galeon problem.) But if it's not a galeon problem, it *looks* like one
>  of those two (if they're really different) to such uninformed users as
>  myself -- and likely gets called one on lists ...
>  
>  Maybe someone here can at least tell why this trouble is chronic with
>  galeon/yum, and yet not with epiphany nor firefox. (I've never encountered
>  it with either, and have been using both for years.) 
Normally I would tell you that you need to address this problem *not*
with us, *nor* with the galeon developers (who have nothing to do with
RPM or yum dependency problems), but on the fedora-list
(http://www.redhat.com/mailman/listinfo/fedora-list/), IRC #fedora or
FedoraForum.org.  But we *did* ask for examples, so here's some free
help with our compliments.  ;-)

I just ran "yum install" and the problem seems obvious to me (and
probably more experienced users), not so much if you're just getting
wet:

[...]
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for galeon to pack into transaction set.
galeon-1.3.21-8.fc4.i386. 100% |=========================|  38 kB
00:00
---> Package galeon.i386 0:1.3.21-8.fc4 set to be updated
--> Running transaction check
--> Processing Dependency: mozilla = 37:1.7.8 for package: galeon
--> Finished Dependency Resolution
Error: Missing Dependency: mozilla = 37:1.7.8 is needed by package
galeon

The galeon package currently in Extras has been packaged to use mozilla
version 1.7.8 (and *only* 1.7.8, that's what the equals sign "=" means).
However:

[pfrields@localhost ~]$ rpm -q mozilla
mozilla-1.7.10-1.5.1

So there's the problem.  The galeon package wants mozilla version 1.7.8,
but 1.7.10 is what's on FC4 currently.  If you query Bugzilla for
information on galeon in Fedora Extras, you'll see a bug open for this
problem.  Expect resolution Real Soon Now.

I'm not sure how we can approach this in the yum tutorial, short of
getting into explaining RPM spec tags such as Requires:.  Let's not do
that.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/

Some thoughts on the yum tutorial -- one example : galeon

[Beartooth]

On Thu, 28 Jul 2005 11:05:55 -0400, Paul W. Frields wrote:

>  On Wed, 2005-07-27 at 16:25 -0400, Beartooth SenectoFlatuloid wrote:
>  [...snip...]
> > As I said there, I have no idea whether this is a yum problem, a repo
> > problem, or something still different. (They seem to be saying it's not
> > a galeon problem.) But if it's not a galeon problem, it *looks* like one
> > of those two (if they're really different) to such uninformed users as
> > myself -- and likely gets called one on lists ...
> > 
> > Maybe someone here can at least tell why this trouble is chronic with
> > galeon/yum, and yet not with epiphany nor firefox. (I've never encountered
> > it with either, and have been using both for years.)
>  
>  Normally I would tell you that you need to address this problem *not*
>  with us, *nor* with the galeon developers (who have nothing to do with
>  RPM or yum dependency problems), but on the fedora-list
>  (http://www.redhat.com/mailman/listinfo/fedora-list/), IRC #fedora or
>  FedoraForum.org.  But we *did* ask for examples, so here's some free
>  help with our compliments.  ;-) 
Yes, that' the only reason I troubled you with it; but thanks a million
for the extra mile!
 
>  I just ran "yum install" and the problem seems obvious to
> me (and
>  probably more experienced users), not so much if you're just getting
>  wet:
>  
>  [...]
>  Resolving Dependencies 
[....]
>  The galeon package currently in Extras has been packaged to use
> mozilla
>  version 1.7.8 (and *only* 1.7.8, that's what the equals sign "=" means).
>  However:
>  
>  [pfrields@localhost ~]$ rpm -q mozilla mozilla-1.7.10-1.5.1
>  
>  So there's the problem.  The galeon package wants mozilla version 1.7.8,
>  but 1.7.10 is what's on FC4 currently.  If you query Bugzilla for
>  information on galeon in Fedora Extras, you'll see a bug open for this
>  problem.  Expect resolution Real Soon Now. 
So, if I understand you right, it amounts to a repo problem? I.e., the
one(s) with galeon have it packaged not to accept versions later than ...?
At any rate, I'm very glad indeed to hear that Real Soon Now!

	Again, many, many thanks!
-- 
Beartooth Senectoflatuloid, Neo-Redneck, Linux Convert
Remember, I have precious little idea what I am talking about.

Some thoughts on the yum tutorial -- one example : galeon

[Paul W. Frields]

On Thu, 2005-07-28 at 13:02 -0400, Beartooth SenectoFlatuloid wrote: 
>  > I just ran "yum install" and the problem seems obvious
> to me (and
>  > probably more experienced users), not so much if you're just getting
>  > wet:
>  > 
>  > [...]
>  > Resolving Dependencies
>  [....]
>  > The galeon package currently in Extras has been packaged to use mozilla
>  > version 1.7.8 (and *only* 1.7.8, that's what the equals sign "="
> means).
>  > However:
>  > 
>  > [pfrields@localhost ~]$ rpm -q mozilla mozilla-1.7.10-1.5.1
>  > 
>  > So there's the problem.  The galeon package wants mozilla version 1.7.8,
>  > but 1.7.10 is what's on FC4 currently.  If you query Bugzilla for
>  > information on galeon in Fedora Extras, you'll see a bug open for this
>  > problem.  Expect resolution Real Soon Now.
>  
>  So, if I understand you right, it amounts to a repo problem? I.e., the
>  one(s) with galeon have it packaged not to accept versions later than ...?
>  At any rate, I'm very glad indeed to hear that Real Soon Now!
>  
>  	Again, many, many thanks! 
Not an overall repo problem, really, but a problem with just that
particular package *in* that repo.  (Which I think is what you meant in
any case.)  Since the repo in question is Fedora Extras, and since I saw
a Bugzilla entry for this specific issue, rest assured it should be
remedied.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/