=========================================== 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. ===========================================
On Tue, 2005-07-26 at 11:42 +0100, Timothy Murphy wrote:
- 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.
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:
- 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?
- 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.
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:
- 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.
- 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 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 :)
- 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.
- 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 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.
- 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 wrote:
- 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.
- 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.
- 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.
On Wed, 2005-07-27 at 11:58 +0100, Timothy Murphy wrote:
Stuart Ellis wrote:
- 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?
- 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.
- 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 wrote:
On Wed, 2005-07-27 at 11:58 +0100, Timothy Murphy wrote:
Stuart Ellis wrote:
- 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>
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:
- 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?
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
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.
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/
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.
On Wed, 27 Jul 2005 11:58:32 +0100, Timothy Murphy wrote:
Stuart Ellis wrote:
- 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.)
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.
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!
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.
On Wed, 2005-07-27 at 01:46 +0100, Stuart Ellis wrote:
- 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.
- 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.
- 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!
- 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.
- 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.
On Wed, 2005-07-27 at 08:06 -0400, Paul W. Frields wrote:
- 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.
- 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.
-
Beartooth -
Ignacio Vazquez-Abrams -
Karsten Wade -
Paul W. Frields -
Stuart Ellis -
Timothy Murphy -
Yoshihiro Totaka