Judging from recent discussions on this list, it seems that many are still confused about configuring their yum.conf files, and about all the different repositories out there. I was wondering what we, the Fedora community, might do to make this easier. I'm not so much thinking about documentation -- it seems to me that FedoraFAQ.org does a pretty good job of explaining stuff to people, however it still requires that they find it or look for it in the first place. I was wondering if there was something that could be done to yum itself (either the client program itself, or the format of yum repositories) to make this easier.
Just off the top of my head, these things strike me as being potentially useful:
1. Yum repositories should have a mirrors.xml file. All the user need do is sign up to the main repository itself, the mirrors.xml file is downloaded, and yum tries to use the mirror that is closest or fastest (I'm not sure *how* it should do that, but lets think of this as an ideal scenario proposal). 2. Yum repositories should be able to announce that they are dependent on other yum repositories: if I sign up to Livna.org I am then automatically signed up to Fedora.us. 3. If 1. can be implemented, then I think the GPG key of the repository should automatically be installed -- because mirrors are determined automatically you only ever sign up to the main repository itself and so automatically retrieving its GPG key should be no more a security issue than manually adding it. 4. I shouldn't need to alter my yum.conf when I upgrade to a new version of FC -- yum should determine which version of FC I am running and automatically use the appropriate repositories (i.e. if I subscribe to rpm.livna.org when running FC2 and then I upgrade to FC3 yum should automatically start using livna's FC3 repository). 5. I should be able to subscribe to a repository from the command line without manually editing yum.conf (i.e. something like "yum subscribe rpm.livna.org"). 6. There should be some way of distinguishing between a repository that is part of Fedora Core, or Fedora Extras or Fedora Alternatives. Subscribing to a repository from Fedora Alternatives should warn the user of potential problems. I'm not sure quite how this should be done, but perhaps have something like "channels" which group repositories (and yum-arch should be altered so that you can't create a yum repository without declaring whether it is Core, Extras or Alternatives). 7. If 6. could be implemented, then "channels" should be able to advise you what other repositories there were in a channel, together with a short description of what the repository provided. This would aid people in finding the right repositories.
If some of these things sound familiar that is because some of them are features of Red Carpet, my favourite software installer and manager. I would have liked to have seen red-carpet/rug/rcd adopted by Fedora Core, but (a) it seems hardly anyone else wanted that, and (b) it looks like Red Carpet may no longer be a standalone product but may have been entirely integrated into Novell ZenWorks for Unix. However, if yum got at least some of the above features I think it would be a vast improvement, and I suspect we would have less problems reported on this list.
I'm really hoping some people might have other suggestions, or comments on what I've said above.
Best, Darren
D. D. Brierton said: [snip]
- Yum repositories should have a mirrors.xml file. All the user
need do is sign up to the main repository itself, the mirrors.xml file is downloaded, and yum tries to use the mirror that is closest or fastest (I'm not sure *how* it should do that, but lets think of this as an ideal scenario proposal).
The version of yum in rawhide already has this. IIRC it does it using the same format as up2date, point it to a text file of repos and it randomly picks one.
[snip]
- If 1. can be implemented, then I think the GPG key of
the repository should automatically be installed
At the bare minimum it should prompt you if you want to install the key. IMHO since this is a once-a-repo operation automation isn't needed. I also like to know what keys I'm installing.
- I shouldn't need to alter my
yum.conf when I upgrade to a new version of FC -- yum should determine which version of FC I am running and automatically use the appropriate repositories (i.e. if I subscribe to rpm.livna.org when running FC2 and then I upgrade to FC3 yum should automatically start using livna's FC3 repository).
If your repos and your yum.conf are created correctly this is already done. That is why the $releasever and $basearch variables exist.
[snip]
- There should be some way of distinguishing
between a repository that is part of Fedora Core, or Fedora Extras or Fedora Alternatives.
[snip]
Of course it would be nice to decide what those terms mean and to what repos they apply first.
On Thu, 2004-10-28 at 19:29, William Hooper wrote:
D. D. Brierton said: [snip]
- Yum repositories should have a mirrors.xml file. All the user
need do is sign up to the main repository itself, the mirrors.xml file is downloaded, and yum tries to use the mirror that is closest or fastest (I'm not sure *how* it should do that, but lets think of this as an ideal scenario proposal).
The version of yum in rawhide already has this. IIRC it does it using the same format as up2date, point it to a text file of repos and it randomly picks one.
Excellent. So all I do is add rpm.livna.org to yum.conf and yum automagically takes care of the rest? Of course, it would be nice if a mirror could be chosen in some non-random way, but I'm really not sure how feasible that is.
[snip]
- If 1. can be implemented, then I think the GPG key of
the repository should automatically be installed
At the bare minimum it should prompt you if you want to install the key.
Yes, I'd be happy with that.
IMHO since this is a once-a-repo operation automation isn't needed. I also like to know what keys I'm installing.
Well, if you add the repository, and you know that yum will automatically install the repository's key, then you would know what key you were installing.
- I shouldn't need to alter my
yum.conf when I upgrade to a new version of FC -- yum should determine which version of FC I am running and automatically use the appropriate repositories (i.e. if I subscribe to rpm.livna.org when running FC2 and then I upgrade to FC3 yum should automatically start using livna's FC3 repository).
If your repos and your yum.conf are created correctly this is already done. That is why the $releasever and $basearch variables exist.
Ah, yes. I'd forgotten that I had that in my yum.conf. I think I was thrown by the number of people on the fedora-test list who were recently saying that yum wasn't finding any updates and it turned out that they were pointing at the wrong repos. They may just have been a testing problem as opposed to a yum problem
[snip]
- There should be some way of distinguishing
between a repository that is part of Fedora Core, or Fedora Extras or Fedora Alternatives.
[snip]
Of course it would be nice to decide what those terms mean and to what repos they apply first.
I thought that was fairly clear: Fedora Core is the packages belonging to the final release of your current version and the packages in Fedora Core Updates Released; Fedora Extras is anything designed specifically to work *with* Fedora Core without in anyway altering anything in Fedora Core; Fedora Alternatives is anything designed to work with Fedora Core which may additionally provide alternative packages of elements of Fedora core or Fedora Extras.
Best, Darren
D. D. Brierton said:
On Thu, 2004-10-28 at 19:29, William Hooper wrote:
D. D. Brierton said: [snip]
- Yum repositories should have a mirrors.xml file. All the user
need do is sign up to the main repository itself, the mirrors.xml file is downloaded, and yum tries to use the mirror that is closest or fastest (I'm not sure *how* it should do that, but lets think of this as an ideal scenario proposal).
The version of yum in rawhide already has this. IIRC it does it using the same format as up2date, point it to a text file of repos and it randomly picks one.
Excellent. So all I do is add rpm.livna.org to yum.conf and yum automagically takes care of the rest?
Umm, no. "point it to a text file of repos and it randomly picks one", just like up2date. For example:
http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc2 [snip]
- There should be some way of distinguishing
between a repository that is part of Fedora Core, or Fedora Extras or Fedora Alternatives.
[snip]
Of course it would be nice to decide what those terms mean and to what repos they apply first.
I thought that was fairly clear:
The concept if fairly clear, but I have yet to see any repo labeled any of those in the real world, or any guidelines from the Fedora on how to advertise yourself as such.
On Thu, 2004-10-28 at 20:49, William Hooper wrote:
D. D. Brierton said:
Excellent. So all I do is add rpm.livna.org to yum.conf and yum automagically takes care of the rest?
Umm, no. "point it to a text file of repos and it randomly picks one", just like up2date. For example:
http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc2
I think we're talking past each other. What I was trying to ask was whether when I upgrade to the next version of yum my current yum.conf will suffice to use mirrors, or whether I have to re-do my yum.conf all over again in order to take advantage of this new functionality. If the latter, then that seems a shame as (a) lots of people won't alter their yum.conf files and the problems will persist of people mailing the list asking why yum is so slow; (b) it just seems that this functionality could just be part of yum's default behaviour.
Of course it would be nice to decide what those terms mean and to what repos they apply first.
I thought that was fairly clear:
The concept if fairly clear, but I have yet to see any repo labeled any of those in the real world,
Well, except for Fedora Core itself! But I know what you mean. But if yum-arch insisted that yum repositories specified whether they were Extras or Alternatives do you think any of the repository owners would have difficulty giving the correct answer?
Best, Darren
D. D. Brierton said:
On Thu, 2004-10-28 at 20:49, William Hooper wrote:
D. D. Brierton said:
Excellent. So all I do is add rpm.livna.org to yum.conf and yum automagically takes care of the rest?
Umm, no. "point it to a text file of repos and it randomly picks one", just like up2date. For example:
http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc2
I think we're talking past each other. What I was trying to ask was whether when I upgrade to the next version of yum my current yum.conf will suffice to use mirrors,
No, because you won't be pointing to the text file of repos.
or whether I have to re-do my yum.conf all over again in order to take advantage of this new functionality.
Yes.
If the latter, then that seems a shame as
Given the alternative of breaking everyone's yum.conf I think it is the right move.
(a) lots of people won't alter their yum.conf files and the problems will persist of people mailing the list asking why yum is so slow;
Only for people that are doing upgrades and have already edited their yum.conf. I would guess that most of the people complaining don't fall into either of those catagories.
I for one don't want my yum.conf automagically edited, because I'm sure that the mirror on my LAN is faster than any mirror that Yum would pick.
(b) it just seems that this functionality could just be part of yum's default behaviour.
It is when using the new config files shipped with FC3.
On Thursday 28 October 2004 15:49, William Hooper wrote:
D. D. Brierton said:
On Thu, 2004-10-28 at 19:29, William Hooper wrote:
D. D. Brierton said: [snip]
- Yum repositories should have a mirrors.xml file. All the user
need do is sign up to the main repository itself, the mirrors.xml file is downloaded, and yum tries to use the mirror that is closest or fastest (I'm not sure *how* it should do that, but lets think of this as an ideal scenario proposal).
The version of yum in rawhide already has this. IIRC it does it using the same format as up2date, point it to a text file of repos and it randomly picks one.
Excellent. So all I do is add rpm.livna.org to yum.conf and yum automagically takes care of the rest?
Umm, no. "point it to a text file of repos and it randomly picks one", just like up2date. For example:
http://fedora.redhat.com/download/up2date-mirrors/updates-released-f c2 [snip]
- There should be some way of distinguishing
between a repository that is part of Fedora Core, or Fedora Extras or Fedora Alternatives.
[snip]
Of course it would be nice to decide what those terms mean and to what repos they apply first.
I thought that was fairly clear:
The concept if fairly clear, but I have yet to see any repo labeled any of those in the real world, or any guidelines from the Fedora on how to advertise yourself as such.
-- William Hooper
You've hit a very large part of the problem square on the head there William. Because there are mirrors here and there, it seems that a truely inclusive mirror list, including the actual location of the machine one might be accessing so one can actually make an intelligent choice as to where to point yum at, is a very elusive, almost a state secret, thing to find. Ask on the list here, and get pointed at the downloads.fedora.redhat machine, a machine thats never served a package up via yum or up2date in chunks bigger than 10k per fitfull 1 or 2 minute intervals. Watching paint dry is more entertaining.
The way it is, one tends to hunt around thru what may be a 30 day old list you've grabbed out of the FAQ or some similar location, pick a site thats got your stuff and can feed you at 50k+/second, edit it into your yum.conf, and the site disappears 4 days later as has been the occasion twice now for out of the states FC2 compatible sites for me.
I've got one box stock FC2 machine that hasn't been updated since the Ooo.i8n package was put up, yum has pulled it probably 25 times now in 3 different day long invocations without getting a good md5sum on the 6 or 7 occasions it managed to get the whole file without puking over a bad header checksum and starting over from byte one. At 3 hours or more per attempt I finally put it into the exclude= line, and I hope the next time I try, it doesn't die from dependency hell. I'm getting the impression that this file is scrambled well before it hits the cat5 cable on the back of the server in Research Triangle Park, which is where I believe that particular yum.conf is pointed.
I love to find a server in Pittsburg, it would be 600+ miles of copper and glass closer to me than the fedora boxes.
Yes, finding a good server sure is a huge secret. Fixing that sure would go a long ways toward making yum a pleasure to use.
Gene Heskett said: [snip]
You've hit a very large part of the problem square on the head there William. Because there are mirrors here and there, it seems that a truely inclusive mirror list, including the actual location of the machine one might be accessing so one can actually make an intelligent choice as to where to point yum at, is a very elusive, almost a state secret, thing to find. Ask on the list here, and get pointed at the downloads.fedora.redhat machine, a machine thats never served a package up via yum or up2date in chunks bigger than 10k per fitfull 1 or 2 minute intervals. Watching paint dry is more entertaining.
I'm not sure what post of mine you were reading...
If you want a list of Fedora core mirrors, it's pretty easy to find:
http://fedora.redhat.com/download/mirrors.html
I'm sure all the other repos have these lists, too. For example:
http://www.fedora.us/wiki/FedoraMirrorList
Physical location is not always a good metric for deciding on mirrors anyway. When I first got my DSL all my packets were going from here in Ohio to Florida before going anywhere else, so picking a physically close server to me would have been a heck of a long trip.
The way it is, one tends to hunt around thru what may be a 30 day old list you've grabbed out of the FAQ or some similar location,
[snip]
Now you've hit the problem. Too many people are convinced that there is some magic in the yum.conf instead of actually trying to understand it. I cringe every time I see someone pointed to a FAQ to get a yum.conf rather than told how to make their own changes.
The beauty of yum is that it uses standard protocols so you can easily look at the repos with your web browser and test to your hearts content with something like wget.
-- William Hooper
On Thu, 28 Oct 2004 19:41:17 -0400, William Hooper wrote:
Now you've hit the problem. Too many people are convinced that there is some magic in the yum.conf instead of actually trying to understand it. I cringe every time I see someone pointed to a FAQ to get a yum.conf rather than told how to make their own changes.
Make that one of the problems, or part of the problem. Some of us would rather run anything than MegaScat, and find linux (especially RedHat & Fedora) somewhat less unapproachable than other distributions -- but can't begin to follow such explanations as we commonly find, even if we're at least mildly interested. (Several of my friends and correspondents refuse even to try linux, despite their dissatisfaction with Windows, because they see indications of the time & effort I put into it.)
Even such as we do notice that running yum is easier than up2date (or, afaict, apt). But without being able to read (let alone write) code, we can at least use a yum.conf if we can copy or download it.
The beauty of yum is that it uses standard protocols so you can easily look at the repos with your web browser and test to your hearts content with something like wget.
What are repos, and why do you look at them? What would you test??
I did use wget once -- with someone walking me through, step by step. I don't have the kind of mind that can recall the details, nor even where to look for them. I remember that it did a great swath of downloading all at once, instead of laboriously one rpm after another ... But even though I know enough to look at man wget, the result is the usual: I'm lost before I get very far. And this is still happening after years of linux.
Beartooth said: [snip]
Even such as we do notice that running yum is easier than up2date (or, afaict, apt). But without being able to read (let alone write) code, we can at least use a yum.conf if we can copy or download it.
a) The yum.conf contains no "code", and doesn't require the ability to write "code" to edit it. If you have the ability to type http://fedora.redhat.com to get Fedora, you have the ability to put a URL in the yum.conf.
b) Downloading and using a random yum.conf is just as bad as running any random e-mail attachment on Windows.
The beauty of yum is that it uses standard protocols so you can easily look at the repos with your web browser and test to your hearts content with something like wget.
What are repos,
repositories of packages.
and why do you look at them?
To verify that you have the correct location in your yum.conf. If the URL doesn't work in your browser, it isn't going to work with yum.
What would you test??
Speed of the repo, that it is reachable, etc.
I did use wget once -- with someone walking me through, step by step.
wget it a very useful tool, and easy to use. Start with "man wget".
On Fri, 29 Oct 2004 22:03:59 -0400, William Hooper wrote:
a) The yum.conf contains no "code", and doesn't require the ability to write "code" to edit it. If you have the ability to type http://fedora.redhat.com to get Fedora, you have the ability to put a URL in the yum.conf.
All right, so I don't know code from gibberish; I'm not surprised. All I really know is that that file is not in English -- nor any other language I can read. But you're still overestimating me. (Thanks for the compliment.) I can type that on either of two machines, and do a download; but I've had miserable results trying to burn CDs -- and haven't even dared try installing anything straight off the net.
The first time I got Fedora, I was sent CDs by an electronic friend. The second time I used ones out of a book I bought.
I have yet to get more off the Net than updates in any way to be able to use it. (I had FC1 running, after a lot of help; gave up on it when I got a flat panel monitor; and got it again when that monitor showed up in the list under Main Menu > System Settings > Display.)
As for putting a URL into a .conf file : the only editor I know is pico; until I learned about the -w switch (You do call it a switch, don't you?), I couldn't preserve line length, indentation, etc., etc. I learned about -w only by asking dumb questions in places like this. Beforehand, no, I couldn't put a URL into a file -- not so that it would work.
b) Downloading and using a random yum.conf is just as bad as running any random e-mail attachment on Windows.
Well, it was hardly random, having been authored for this list by a regular here. And it works. And hasn't broken anything.
What would you test??
Speed of the repo, that it is reachable, etc.
I did use wget once -- with someone walking me through, step by step.
wget it a very useful tool, and easy to use. Start with "man wget".
I did. And despaired. Wget's man page is one of the worst: you have to have an advanced CS degree just to be able to keep your place in it, let alone find anything you can understand.
Don't get me wrong: I'm sure such man pages are very useful to many here; but after more time and effort spent on linux than most people I know would dream of, I still can't begin to make any use of most. That's why I label so many of my posts VDQ : Very Dumb Question.
I run linux not only because it's not MS, but because I know virtually anything *can* be tweaked to suit the way I use it -- *after* I've learned to use it, if that's within my capability -- and someone online will probably tell me how to do the tweak if I try to find it and don't, or find it and don't understand it.
How many languages would anyone here use, if before you learned any you had to be able to compare and contrast the history of Balto-Fennic versus Indo-European grammar and phonology? I can do that -- but I didn't get to the ability by learning it *before* all the languages I know. Man pages are great for those who were present at their creation, and have followed along during their growth -- or so I presume, secondhand -- but many, such as wget, are a barrier and not an aid to the uninstructed.
On Sat, 2004-10-30 at 14:12 -0400, Beartooth wrote:
On Fri, 29 Oct 2004 22:03:59 -0400, William Hooper wrote:
a) The yum.conf contains no "code", and doesn't require the ability to write "code" to edit it. If you have the ability to type http://fedora.redhat.com to get Fedora, you have the ability to put a URL in the yum.conf.
All right, so I don't know code from gibberish; I'm not surprised. All I really know is that that file is not in English -- nor any other language I can read. But you're still overestimating me. (Thanks for the compliment.) I can type that on either of two machines, and do a download; but I've had miserable results trying to burn CDs -- and haven't even dared try installing anything straight off the net.
The first time I got Fedora, I was sent CDs by an electronic friend. The second time I used ones out of a book I bought.
I have yet to get more off the Net than updates in any way to be able to use it. (I had FC1 running, after a lot of help; gave up on it when I got a flat panel monitor; and got it again when that monitor showed up in the list under Main Menu > System Settings > Display.)
As for putting a URL into a .conf file : the only editor I know is pico; until I learned about the -w switch (You do call it a switch, don't you?), I couldn't preserve line length, indentation, etc., etc. I learned about -w only by asking dumb questions in places like this. Beforehand, no, I couldn't put a URL into a file -- not so that it would work.
The yum configuration file is fairly simple, to look at, with a little bit of familiarity and deductive reasoning.
You have on the first line [main] this depicts a group. so the lines below it are relevant to the group "main". In this case, the "group" controls how yum, in general works.
Some entries in here are quite self explanitory, for example
logfile=/var/log/yum.log
This tells yum where to record it's log information.
Other lines are FAR from obvious, for example tolerant=1, I havn't the foggiest what this means, on checking the man page, this doesn't tell me either. Only place to find out what that line means is here, or IRC or some where else you may gain the ear of the experienced.
We soon hit another line that is as follows [base] As we had assertained with [main] we now have another "group". How do we know what this group is for? Looking down we see several of these entries, with things like "name", "baseurl" and some other entries. For me, it told me that we are now looking at "repositories", groups where packages can be obtained from.
A simple repository will look like this
[group name, internal to yum] name=Happy freindly name for user to see, when information is printed to the screen baseurl=<http/ftp/file location of "yum" files available to install>
That is it.
Both the information in [] and the "name=" is completely arbitrary, and has no "real" meaning other then information. The "baseurl" must have valid information, and that is the location of the yum files. To my knowledge, a "yum repository" must contain several peices of information. They are as follows (for the newest version of yum, slightly different to the one your using on FC2). 1. Header files: There is one of these for each rpm package, it contains certain information, I believe things like dependancy information. 2. RPM files: The actual packages to be installed 3. Several xml files who's names I care little to remember. These are there to speed up the use of yum. If your really curious some one here who knows more about them can tell you.
This "should" give you enough to start writing your own yum.conf files (or in the case of the new yum, adding your own "repo configuration files" under /etc/yum.repos.d/<indevidual repo files>.repo
Did that help at all?
b) Downloading and using a random yum.conf is just as bad as running any random e-mail attachment on Windows.
Well, it was hardly random, having been authored for this list by a regular here. And it works. And hasn't broken anything.
What would you test??
Speed of the repo, that it is reachable, etc.
I did use wget once -- with someone walking me through, step by step.
wget it a very useful tool, and easy to use. Start with "man wget".
I did. And despaired. Wget's man page is one of the worst: you have to have an advanced CS degree just to be able to keep your place in it, let alone find anything you can understand.
Don't get me wrong: I'm sure such man pages are very useful to many here; but after more time and effort spent on linux than most people I know would dream of, I still can't begin to make any use of most. That's why I label so many of my posts VDQ : Very Dumb Question.
I run linux not only because it's not MS, but because I know virtually anything *can* be tweaked to suit the way I use it -- *after* I've learned to use it, if that's within my capability -- and someone online will probably tell me how to do the tweak if I try to find it and don't, or find it and don't understand it.
How many languages would anyone here use, if before you learned any you had to be able to compare and contrast the history of Balto-Fennic versus Indo-European grammar and phonology? I can do that -- but I didn't get to the ability by learning it *before* all the languages I know. Man pages are great for those who were present at their creation, and have followed along during their growth -- or so I presume, secondhand -- but many, such as wget, are a barrier and not an aid to the uninstructed.
I hear you here, some man files are absolutely horrible to try and understand, try learning regular expressions, or have a look at man awk or man sed. Trust me, man wget is a pussy cat ;)
Hopefully, you have the feeling that you can come to the community and seek assistance, so that we can all get through it ;)
On Sun, 31 Oct 2004 23:15:29 +0000, Douglas Furlong wrote:
Hopefully, you have the feeling that you can come to the community and seek assistance, so that we can all get through it ;)
I do indeed, and will study your exposition; many thanks!
In fact, I try to do more. Because I'm subtechnoid, but also articulate, I make a practice of trying to get across, on lists like this, the one thing the real Alpha Technoids have most trouble with most often, afaict : why it is that the uninitiated have such difficulty doing what seems child's play to them. That, if anything, is what I can give back.
And it is getting back, whether because of any efforts of mine, or independently of them, or despite them. Linux has been getting more user-friendly by leaps and bounds in my time.
For example, the user I know best never managed to get RH 6.0 nor 6.1 installed at all; had to have a Friendly Local Alpha Geek (FLAG) install 7.2; participated (a little) in installing 8.0 at an installfest; installed RH9 at home, with help from the local LUG; and has installed FC1 twice, with a lot of help from the local LUG the first time, and with only a (relatively) little trouble the second. Everything works on one machine, and most things do on the other.
All this in a matter of five or six years is real progress, however frustrating it does get at times.
Beartooth wrote:
And it is getting back, whether because of any efforts of mine, or independently of them, or despite them. Linux has been getting more user-friendly by leaps and bounds in my time.
Really? In my experience it has been getting steadily worse.
For example, the user I know best never managed to get RH 6.0 nor 6.1 installed at all; had to have a Friendly Local Alpha Geek (FLAG) install 7.2; participated (a little) in installing 8.0 at an installfest; installed RH9 at home, with help from the local LUG; and has installed FC1 twice, with a lot of help from the local LUG the first time, and with only a (relatively) little trouble the second. Everything works on one machine, and most things do on the other.
Again, my experience is exactly the opposite. RH-8.0 installed on all my computers, without any major problems, as did earlier RH distributions.
The kernel in RH-9.0 did not run on my SCSI-only machine, and neither has any Fedora version since.
X11 has always worked for me on all my machines, until Fedora-2, when the change to Xorg meant it no longer ran on my Sony Picturebooks. (I had to re-compile X after applying patches in the Xorg bugzilla, which for some reason were completely ignored for 6 months.)
All this in a matter of five or six years is real progress, however frustrating it does get at times.
As I said, my experience is exactly the opposite. I have some doubts about the direction of the Fedora project. Basically, testing out new ideas for Redhat, and trying to make a solid system, may be contradictory.
I used to give out Redhat CDs to students, but I'd be reluctant to give out Fedora CDs, as I suspect I would be inundated with problems.
Has anyone here experiened problem similar to those?
Again, my experience is exactly the opposite. RH-8.0 installed on all my computers, without any major problems, as did earlier RH distributions.
The kernel in RH-9.0 did not run on my SCSI-only machine, and neither has any Fedora version since.
________________________________________________________________________ Gustavo Seabra - Graduate Student E-Mail: seabra@ksu.edu Phone: (785) 532-6072 Chemistry Department Kansas State University Manhattan, KS 66506-3701
Timothy Murphy wrote:
Beartooth wrote:
Again, my experience is exactly the opposite. RH-8.0 installed on all my computers, without any major problems, as did earlier RH distributions.
The kernel in RH-9.0 did not run on my SCSI-only machine, and neither has any Fedora version since.
X11 has always worked for me on all my machines, until Fedora-2, when the change to Xorg meant it no longer ran on my Sony Picturebooks. (I had to re-compile X after applying patches in the Xorg bugzilla, which for some reason were completely ignored for 6 months.)
I used to give out Redhat CDs to students, but I'd be reluctant to give out Fedora CDs, as I suspect I would be inundated with problems.
My experiences are that it is improving over RH 8 in alot of ways. The tools are what makes the difference. RH 6 worked well on my older (P90) computer. RH 7 was slower and I stopped there on that machine.
As software upgrades, some tools won't work on older hardware but that isn't just with Linux or Fedora, but also from that other major software that requires major hardware upgrades every time there is a new release.
Red Hat is following a stricter licence policy than other distributers but that is there decision. This is where yum comes in, if there was a decent frontend. With the litigation issues in the US, this makes sense. There was an article today that points to issues with Open source software and legal issues.
Whatdya mean, free software? http://www.theregister.co.uk/2004/11/02/issues_with_open_source/
"However open source products can, unwittingly, violate patents and the owner of the patent can legitimately sue the user of the open source. The lawyers go after the money rather than the source of the violation, which means targeting users, as SCO has. The legal risk is probably much higher in the US than elsewhere, as the US is more of a litigious society."
Red Hat, I feel is making decisions based on these risks and in your case they are not the best decisions.
Support for SCSI is interesting as I havn't had any problems with SCSI on any computer since my early slackware and Adaptec controllers in 1994.
Hey, I purchased a new computer and I couldn't get may video card to work with Fedora, even using the "manufacturs" supplied drivers. I had to change the card. I don't blame Fedora for this though.
Robin Laing wrote:
The kernel in RH-9.0 did not run on my SCSI-only machine, and neither has any Fedora version since.
X11 has always worked for me on all my machines, until Fedora-2, when the change to Xorg meant it no longer ran on my Sony Picturebooks. (I had to re-compile X after applying patches in the Xorg bugzilla, which for some reason were completely ignored for 6 months.)
My experiences are that it is improving over RH 8 in alot of ways. The tools are what makes the difference. RH 6 worked well on my older (P90) computer. RH 7 was slower and I stopped there on that machine.
I'm only talking about whether a distribution does or does not work.
Another example: I haven't been able to install or upgrade any Redhat or Fedora distribution on my Sony Picturebooks by CD since Redhat-8.0. They simply don't have drivers for this standard Sony CD reader. I've had to upgrade by bringing the ISO files over by WiFi, and installing from the hard disk.
My impression is that the Fedora team are just not that interested in ensuring that their CDs install on as many machines as possible. They give more time and attention to other issues.
Knoppix seems much better at this than Fedora.
The old system, where you had a choice of floppies to start from, had a lot to recommend it.
Of course this isn't the only thing that matters, or even the most important. But I still think that things have got worse, not better, as far as installation is concerned.
I have wondered why yum is used instead of something that feels more polished such as rug with it's very user-friendly client Red Carpet? It seems to be GPL as is the required server software needed, OpenCarpet. It seems much more professional and polished to me. I like it better than yum or apt.
On Thu, 2004-11-04 at 00:14 -0800, Michael wrote:
I have wondered why yum is used instead of something that feels more polished such as rug with it's very user-friendly client Red Carpet? It seems to be GPL as is the required server software needed, OpenCarpet. It seems much more professional and polished to me. I like it better than yum or apt.
And you are more than welcome to use it in that case... one of the beauties and freedoms of Open Source Software.
However, Red Hat, Inc. and the Fedora Project have chosen to develop and support the up2date package management program, and Fedora also includes and supports Seth Vidal's yum package management program.
Apt is not specifically supported, nor is Red Carpet. They cannot support *everything*... you are certainly allowed to use it, but the distro has chosen to use and prefer up2date and yum.
Cheers,
William Hooper wrote:
D. D. Brierton said: [snip]
- Yum repositories should have a mirrors.xml file. All the user
need do is sign up to the main repository itself, the mirrors.xml file is downloaded, and yum tries to use the mirror that is closest or fastest (I'm not sure *how* it should do that, but lets think of this as an ideal scenario proposal).
The version of yum in rawhide already has this. IIRC it does it using the same format as up2date, point it to a text file of repos and it randomly picks one.
Sorry, just to get back to this point and other on other posts.
For the majority of people it would be serious advantage to grab a mirror in their geographic location. I fully agree with your arguments against it, they make sense.
I have a few download sites "guessing" my geographic location. I haven't found a wrong one yet. But perhaps based on your arguments, make a geographic locator the default, and allow the Gurus to switch it off?
Please remember not everybody using Linux lives in the States. Believe me, grabbing a local mirror for me here (Australia) is the only thing that makes sense. The random feature of up2date is useless to me as it is.
We should consider it, with option to not use it in my opinion.
my 2c
Regards, Ed.
Edward said:
Please remember not everybody using Linux lives in the States. Believe me, grabbing a local mirror for me here (Australia) is the only thing that makes sense. The random feature of up2date is useless to me as it is.
Multiple geographical lists already exist.
http://fedora.redhat.com/download/up2date-mirrors/
On 10/28/2004 11:14:17 AM, D. D. Brierton wrote:
Judging from recent discussions on this list, it seems that many are still confused about configuring their yum.conf files, and about all the different repositories out there.
With the new /etc/yum.repos.d this will be less of an issue. install a noarch rpm that puts the repo in /etc/yum.repos.d
I was wondering if there was something that could be done to yum itself (either the client program itself, or the format of yum repositories) to make this easier.
Well, people could read the instructions. But each repo having a simple noarch rpm that installs a single file in repos.d will go a long way.
2. Yum repositories should be able to announce that they are dependent on other yum repositories: if I sign up toLivna.org I am then automatically signed up to Fedora.us.
No. livna specifically states you need fedora.us - and that's the way it should be. Do not automagically add any repos.
3. If 1. can be implemented, then I think the GPG key of the repository should automatically be installed
No. a gpg key should be installed only by the system administrator. What should happen is the Fedora base gpg key is installed at install, and by default yum requires gpg key.
Then when you add fedora.us and rpm.livna.org - installing packages via yum will fail if you don't have the gpg key. But they should not be auto installed. The info page for the repository should point to where it is at.
4. I shouldn't need to alter my yum.conf when I upgrade to a new version of FC -- yum should determine which version of FC Iam running
It already has that capability. I don't remember if it uses it or not, but yum has ability to get version info from /etc/redhat-release
5. I should be able to subscribe to a repository from thecommand line without manually editing yum.conf (i.e. something like "yum subscribe rpm.livna.org").
I'm not a yum developer - but I am planning to sort of add this to yum (as soon as I feel comfortable with python) by Elektrifying yum - so that yum can use the elektra registry for repositories.
But anyway - what you describe can already be done with current yum - wget location/fc3/repo.conf && mv repo.conf /etc/yum.repos.d/
6. There should be some way of distinguishing between arepository that is part of Fedora Core, or Fedora Extras or Fedora Alternatives. Subscribing to a repository from Fedora Alternatives should warn the user of potential problems.
Fedora Core should not show bias towards fedora.us repository. However - I think it would be nice to warn when packages installed by Fedora Core are set to be replaced by non Fedora Core packages.
That though would require the vendor tag be used, that's the best way to do that - through rpm and not yum - though yum would have to catch rpm's warning and inform the user.
In fact - that would be nice in general. That would be a nice enhancement to rpm - a config file option to have rpm reject updates to a package that are not from the same vendor, and tie the gpg sig to the vendor.
Can rpm do this now?
On Thu, 2004-10-28 at 19:51, Michael A. Peters wrote:
On 10/28/2004 11:14:17 AM, D. D. Brierton wrote:
Judging from recent discussions on this list, it seems that many are still confused about configuring their yum.conf files, and about all the different repositories out there.
With the new /etc/yum.repos.d this will be less of an issue. install a noarch rpm that puts the repo in /etc/yum.repos.d
That sounds interesting. Is that functionality proposed or actually available in the latest yum? Would this noarch repo rpm be automatically downloaded and installed by yum from some simpler incantation, like "yum subscribe rpm.livna.org" or do you have to manually go and find it and install it by hand?
I was wondering if there was something that could be done to yum itself (either the client program itself, or the format of yum repositories) to make this easier.
Well, people could read the instructions.
Yes, I know they could. But sometimes its nice when things "just work".
But each repo having a simple noarch rpm that installs a single file in repos.d will go a long way.
Yes, that sounds like a big improvement.
2. Yum repositories should be able to announce that they are dependent on other yum repositories: if I sign up toLivna.org I am then automatically signed up to Fedora.us.
No. livna specifically states you need fedora.us - and that's the way it should be. Do not automagically add any repos.
Why not? I know that livna clearly states this dependency, but why can't yum take care of the dependency for you. Otherwise why bother to use yum at all? You could just use rpm and take care of the dependencies yourself.
3. If 1. can be implemented, then I think the GPG key of the repository should automatically be installedNo. a gpg key should be installed only by the system administrator.
Surely the system administrator would be the one running yum.
What should happen is the Fedora base gpg key is installed at install, and by default yum requires gpg key.
But that is so user-unfirendly. How about yum prompting you to install the gpg key, and when you say yes it automatically installs it for you?
Then when you add fedora.us and rpm.livna.org - installing packages via yum will fail if you don't have the gpg key. But they should not be auto installed. The info page for the repository should point to where it is at.
I really don't understand why that is more secure then yum prompting you with something like this:
Install the GPG key for rpm.livna.org from http://rpm.livna.org/RPM-LIVNA-GPG-KEY? [y/N]
and on typing "y" it fetches it for you and installs it.
4. I shouldn't need to alter my yum.conf when I upgrade to a new version of FC -- yum should determine which version of FC Iam running
It already has that capability. I don't remember if it uses it or not, but yum has ability to get version info from /etc/redhat-release
Yes, that was my mistake. I was confused by some messages on fedora-test.
5. I should be able to subscribe to a repository from thecommand line without manually editing yum.conf (i.e. something like "yum subscribe rpm.livna.org").
I'm not a yum developer - but I am planning to sort of add this to yum (as soon as I feel comfortable with python) by Elektrifying yum - so that yum can use the elektra registry for repositories.
Sounds excellent.
But anyway - what you describe can already be done with current yum - wget location/fc3/repo.conf && mv repo.conf /etc/yum.repos.d/
Except that is rather less discoverable.
6. There should be some way of distinguishing between arepository that is part of Fedora Core, or Fedora Extras or Fedora Alternatives. Subscribing to a repository from Fedora Alternatives should warn the user of potential problems.
Fedora Core should not show bias towards fedora.us repository.
No, I agree. I was suggesting that users be made aware of the differences between packages from Fedora Core ("official" packages), Fedora Extras (additional programs that won't alter Fedora Core), and Fedora Alternatives (additional programs that might alter either or both of Fedora Core and Fedora Extras).
However - I think it would be nice to warn when packages installed by Fedora Core are set to be replaced by non Fedora Core packages.
Exactly my thinking.
That though would require the vendor tag be used, that's the best way to do that - through rpm and not yum - though yum would have to catch rpm's warning and inform the user.
Hmmm. The trouble is that I want to distinguish between Fedora Extras and Fedora Alternatives as well, and I don't see how you can do that with the vendor tag, which is why I was thinking of "channels".
Best, Darren
D. D. Brierton kirjoitti viestissään (lähetysaika torstai, 28. lokakuuta 2004 22:34):
That sounds interesting. Is that functionality proposed or actually available in the latest yum?
It's in the current Rawhide/development version, and it will be in FC3.
Would this noarch repo rpm be automatically downloaded and installed by yum from some simpler incantation, like "yum subscribe rpm.livna.org" or do you have to manually go and find it and install it by hand?
If the repository makes such a rpm, it can be installed by the usual "yum install" way. Maybe there should be a standard for naming them, e.g. "repo-livna-<version>-noarch.rpm". The GPG key could be included in the same rpm.
Markku Kolkka kirjoitti viestissään (lähetysaika perjantai, 29. lokakuuta 2004 01:26):
The GPG key could be included in the same rpm.
Sorry, it's 1:30 AM here and it took me several seconds after sending the message to figure out the problem with that...
On Fri, 2004-10-29 at 01:26 +0300, Markku Kolkka wrote:
D. D. Brierton kirjoitti viestissään (lähetysaika torstai, 28. lokakuuta 2004 22:34):
<snip>
Would this noarch repo rpm be automatically downloaded and installed by yum from some simpler incantation, like "yum subscribe rpm.livna.org" or do you have to manually go and find it and install it by hand?
If the repository makes such a rpm, it can be installed by the usual "yum install" way. Maybe there should be a standard for naming them, e.g. "repo-livna-<version>-noarch.rpm". The GPG key could be included in the same rpm.
-- Markku Kolkka markku.kolkka@iki.fi
There is a slight problem with this, yum install repo-livna-blah blah blah would require yum to already have the repo listed.
So what may make MORE sense, is to one repo, where people like freshrpm's, livna, dag's et all submit there "repo rpm".
Then, for a user to have to subscribe to one additional repository and from then on, if they want to gain access to more repositories, they just have to do yum install repo-<repository> blah blahblah.
I believe with this, you could then have the GPG key installed at the same time as an additional repo file is placed in /etc/yum.repos.d/ and for dependencies like livna and fedora.us to also be resolved.
I would suggest that the above "Repository of Repositories" be configured by fedora at install time, but I doubt that will happen. However, I think it is fairly reasonable to expect a user to install 2 rpm's which would configure the Repo, and add the key.
I think this should be very easy to configure, we would just need some one to volunteer to host the repo (fedora.us?), and for other repo's to then create and submit an RPM for their systems.
One possible problem though, is how responsible is fedora.us for the "stability" of those repositories, to make sure they play nice with each other? I can see down the road them possible receiving a lot of flack for repo's that do not play well together.
Douglas Furlong said:
There is a slight problem with this, yum install repo-livna-blah blah blah would require yum to already have the repo listed.
So what may make MORE sense, is to one repo, where people like freshrpm's, livna, dag's et all submit there "repo rpm".
Does this really give any advantages over:
rpm -i http://my.new.repo.com/repo-blah.noarch.rpm
Once you try to go the "one repo" approach you have to take politics into consideration. Most of those repos will never go on an "official" list from Fedora (because of the legal concerns). And there are already packaging conflicts with just the three you listed.
On Fri, 2004-10-29 at 08:19 -0400, William Hooper wrote:
Douglas Furlong said:
There is a slight problem with this, yum install repo-livna-blah blah blah would require yum to already have the repo listed.
So what may make MORE sense, is to one repo, where people like freshrpm's, livna, dag's et all submit there "repo rpm".
Does this really give any advantages over:
The advantage is that you would not have to go searching to see what repo's are available. Admittedly things like fedoratracker makes this job less cumbersome.
Once you try to go the "one repo" approach you have to take politics into consideration. Most of those repos will never go on an "official" list from Fedora (because of the legal concerns). And there are already packaging conflicts with just the three you listed.
Yes, I understand all of that, and mentioned most of it in the post (stating that this would not be an out of the box set up, couldn't be bothered to type it all out as it's been bashed through many times on the list, and I agree with Fedora's stance).
With regards to the conflicts, I also pointed that out.
I'm not giving an answer to every thing, I'm making a suggestion, for hopefully some one to come back with a positive agreement/disagreement with what I suggested.
Douglas Furlong wrote:
Yes, I understand all of that, and mentioned most of it in the post (stating that this would not be an out of the box set up, couldn't be bothered to type it all out as it's been bashed through many times on the list, and I agree with Fedora's stance).
With regards to the conflicts, I also pointed that out.
I'm not giving an answer to every thing, I'm making a suggestion, for hopefully some one to come back with a positive agreement/disagreement with what I suggested.
I will echo these comments.
The biggest issue with yum.conf that I have found is knowing the correct text to put into it. It is all and well to follow an example but if one site is slightly different, then you could spend along time wondering how you screwed up. I have been there.
The idea of a distro list being part of the main updates would also provide a list of repositories that work, partially work or really suspect within the fedora standard model. The user could then un-comment the various repos' as required or wanted. This is where a simple graphical front end would come in handy. It doesn't deal with the mirror issue.
Adding an application like yumi then allows a user to look at all the various applications on those sites. As I have two children, I was looking for games and I was surprised by the number of games that were available from various repos. It was finding them that was a problem.
A yum.conf.YYMMDD file that is downloaded as part of updates with a list of all repositories. Or a better list of all the fedora repositories on a central site, with yum.conf examples that can be cut and pasted would be a start.
Keep things simple for the new users. I have heard people that have tried Fedora or linux state that they cannot find applications. This would make it much easier. We still need a integrated graphical package manager for the former windows crowd that doesn't know a command line from source code.
I like yumi but I also like command line. Yumi provides a great way to see or search for applications in a quick way from accepted repositories. It is a start. gyum is just another version of yumi.
On Thu, 2004-10-28 at 11:51, Michael A. Peters wrote:
On 10/28/2004 11:14:17 AM, D. D. Brierton wrote:
Judging from recent discussions on this list, it seems that many are still confused about configuring their yum.conf files, and about all the different repositories out there.
With the new /etc/yum.repos.d this will be less of an issue. install a noarch rpm that puts the repo in /etc/yum.repos.d
I was wondering if there was something that could be done to yum itself (either the client program itself, or the format of yum repositories) to make this easier.
Well, people could read the instructions. But each repo having a simple noarch rpm that installs a single file in repos.d will go a long way.
2. Yum repositories should be able to announce that they are dependent on other yum repositories: if I sign up toLivna.org I am then automatically signed up to Fedora.us.
No. livna specifically states you need fedora.us - and that's the way it should be. Do not automagically add any repos.
3. If 1. can be implemented, then I think the GPG key of the repository should automatically be installedNo. a gpg key should be installed only by the system administrator. What should happen is the Fedora base gpg key is installed at install, and by default yum requires gpg key.
Then when you add fedora.us and rpm.livna.org - installing packages via yum will fail if you don't have the gpg key. But they should not be auto installed. The info page for the repository should point to where it is at.
4. I shouldn't need to alter my yum.conf when I upgrade to a new version of FC -- yum should determine which version of FC Iam running
It already has that capability. I don't remember if it uses it or not, but yum has ability to get version info from /etc/redhat-release
5. I should be able to subscribe to a repository from thecommand line without manually editing yum.conf (i.e. something like "yum subscribe rpm.livna.org").
I'm not a yum developer - but I am planning to sort of add this to yum (as soon as I feel comfortable with python) by Elektrifying yum - so that yum can use the elektra registry for repositories.
But anyway - what you describe can already be done with current yum - wget location/fc3/repo.conf && mv repo.conf /etc/yum.repos.d/
6. There should be some way of distinguishing between arepository that is part of Fedora Core, or Fedora Extras or Fedora Alternatives. Subscribing to a repository from Fedora Alternatives should warn the user of potential problems.
Fedora Core should not show bias towards fedora.us repository. However - I think it would be nice to warn when packages installed by Fedora Core are set to be replaced by non Fedora Core packages.
That though would require the vendor tag be used, that's the best way to do that - through rpm and not yum - though yum would have to catch rpm's warning and inform the user.
In fact - that would be nice in general. That would be a nice enhancement to rpm - a config file option to have rpm reject updates to a package that are not from the same vendor, and tie the gpg sig to the vendor.
Can rpm do this now?
So the yum.conf at fedora.org is OK?
Tim...
D. D. Brierton wrote:
1. Yum repositories should have a mirrors.xml file. All the user need do is sign up to the main repository itself, the mirrors.xml file is downloaded, and yum tries to use the mirror that is closest or fastest (I'm not sure *how* it should do that, but lets think of this as an ideal scenario proposal).
agreed
2. Yum repositories should be able to announce that they are dependent on other yum repositories: if I sign up to Livna.org I am then automatically signed up to Fedora.us.
Well, there is a rather large red box on Livna announcing such http://rpm.livna.org/ ;-), but I can see your point about having yum do that check for us.
3. If 1. can be implemented, then I think the GPG key of the repository should automatically be installed -- because mirrors are determined automatically you only ever sign up to the main repository itself and so automatically retrieving its GPG key should be no more a security issue than manually adding it.
Have a check box that the user selects the repos and when selected, the keys are added. Good call on this one!
4. I shouldn't need to alter my yum.conf when I upgrade to a new version of FC -- yum should determine which version of FC I am running and automatically use the appropriate repositories (i.e. if I subscribe to rpm.livna.org when running FC2 and then I upgrade to FC3 yum should automatically start using livna's FC3 repository).
This was a pain when I moved from FC1 to FC3. The directory structure changed, and broke yum.conf -- that's why we see fedorafaq.org having to maintain two different yum.conf's.
5. I should be able to subscribe to a repository from the command line without manually editing yum.conf (i.e. something like "yum subscribe rpm.livna.org").
kinda like the "addmedia" is with Mandrake's urpmi.
Clint
On Thu, 28 Oct 2004 19:14:17 +0100, D. D. Brierton wrote:
Judging from recent discussions on this list, it seems that many are still confused about configuring their yum.conf files, and about all the different repositories out there. I was wondering what we, the Fedora community, might do to make this easier. [snipperoo]
If by any chance this means, as I hope, that some few of you are interested in making Fedora usable by subtechnoids, you may also find it helpful to know that, as of now, DDB's post and the one from Clint Harshaw following it up both make good sense to one such.
All the rest are well over my head -- and I've been running linux since RH 7.2, with a lot of help from the helpful.
Nota Bene : I don't in the least mean to diss any of the other posts. My experience is that those who get really good at a thing reach a point where it becomes hard to envision what life would be like, *not* knowing all they do, and therefore welcome such comments. I hope mine help.
D. D. Brierton wrote:
Judging from recent discussions on this list, it seems that many are still confused about configuring their yum.conf files, and about all the different repositories out there. I was wondering what we, the Fedora community, might do to make this easier. I'm not so much thinking about documentation -- it seems to me that FedoraFAQ.org does a pretty good job of explaining stuff to people, however it still requires that they find it or look for it in the first place. I was wondering if there was something that could be done to yum itself (either the client program itself, or the format of yum repositories) to make this easier.
I'm really hoping some people might have other suggestions, or comments on what I've said above.
Best, Darren
Another option would be an easier frontend that would allow easy editting of yum.conf file.
A generic list of locations that could be checked or unchecked to select the sites, mirrors and backups. The admin could then select with repo's would be used. Warnings about possible conflicts and signitures would then be dealt with at one time.
Why should a new user with no knownledge have to struggle to find software and sites. Manually configure a file and then hope it works when a graphical frontend could do all that. How hard would it be for redhat or fedora.us to have a central file of all repositories and mirrors generated into a single array that can be used in a frontend?
Necessary locations could be in a green or must have repo's list. Yellow for repo's that are supportive of the main distro's and red for lists that may not work with or between distro's.
These points are in line with what you are asking for.
Along with a graphical package manager.
On Thu, 2004-10-28 at 21:20, Robin Laing wrote:
Another option would be an easier frontend that would allow easy editting of yum.conf file.
A generic list of locations that could be checked or unchecked to select the sites, mirrors and backups. The admin could then select with repo's would be used. Warnings about possible conflicts and signitures would then be dealt with at one time.
Why should a new user with no knownledge have to struggle to find software and sites. Manually configure a file and then hope it works when a graphical frontend could do all that. How hard would it be for redhat or fedora.us to have a central file of all repositories and mirrors generated into a single array that can be used in a frontend?
Necessary locations could be in a green or must have repo's list. Yellow for repo's that are supportive of the main distro's and red for lists that may not work with or between distro's.
These points are in line with what you are asking for.
Along with a graphical package manager.
In other words, "Why can't we just use Red Carpet?"! I agree with pretty much everything you said, and annoyingly a GPL solution already exists but we aren't going to be using it. The fact that Red Carpet's future looks to be one in which it is no longer a standalone product is of course a pertinent issue, but the lack of interest in using it even before then strikes me as having more to do with "Not Invented Here" syndrome then anything else.
Best, Darren
D. D. Brierton wrote:
On Thu, 2004-10-28 at 21:20, Robin Laing wrote:
Another option would be an easier frontend that would allow easy editting of yum.conf file.
A generic list of locations that could be checked or unchecked to select the sites, mirrors and backups. The admin could then select with repo's would be used. Warnings about possible conflicts and signitures would then be dealt with at one time.
Why should a new user with no knownledge have to struggle to find software and sites. Manually configure a file and then hope it works when a graphical frontend could do all that. How hard would it be for redhat or fedora.us to have a central file of all repositories and mirrors generated into a single array that can be used in a frontend?
Necessary locations could be in a green or must have repo's list. Yellow for repo's that are supportive of the main distro's and red for lists that may not work with or between distro's.
These points are in line with what you are asking for.
Along with a graphical package manager.
In other words, "Why can't we just use Red Carpet?"! I agree with pretty much everything you said, and annoyingly a GPL solution already exists but we aren't going to be using it. The fact that Red Carpet's future looks to be one in which it is no longer a standalone product is of course a pertinent issue, but the lack of interest in using it even before then strikes me as having more to do with "Not Invented Here" syndrome then anything else.
Best, Darren
We used to have an rpm package manager that wasn't to bad.
I don't know Red Carpet, but will it work as a command line tool? This is one issue that must be addressed with any update package.
I find yum works quite well. I have used yumi and gyum as graphical front ends with good success. Improve the frontend and the wheel may have been re-invented. :)
On Thu, 2004-10-28 at 22:00, Robin Laing wrote:
I don't know Red Carpet, but will it work as a command line tool?
Yes, it has a command line tool called rug.
This is one issue that must be addressed with any update package.
Agreed.
I find yum works quite well. I have used yumi and gyum as graphical front ends with good success. Improve the frontend and the wheel may have been re-invented. :)
I have nothing against yum from a technical standpoint. I do have ergonomic issues with it. I agree that a good graphical front end to yum is desperately needed, but some of the functionality that I think is missing and which I described in my original post needs to be in yum itself.
I wonder if the red-carpet codebase could be used as a starting point for a yum front end? It really was excellent ...
Best, Darren
-
Beartooth -
Clint Harshaw -
D. D. Brierton -
Douglas Furlong -
Edward Dekkers -
Gene Heskett -
Gustavo Seabra -
Markku Kolkka -
Michael -
Michael A. Peters -
Robin Laing -
Rodolfo J. Paiz -
Tim -
Timothy Murphy -
William Hooper