1:14 p.m.
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 darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
1:29 p.m.
D. D. Brierton said:
[snip]
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).
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]
3. 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.
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).
If your repos and your yum.conf are created correctly this is already
done. That is why the $releasever and $basearch variables exist.
[snip]
6. 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.
--
William Hooper
2:21 p.m.
On Thu, 2004-10-28 at 19:29, William Hooper wrote:
D. D. Brierton said:
[snip]
> 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).
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]
> 3. 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.
> 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).
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]
> 6. 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 darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
2:49 p.m.
D. D. Brierton said:
On Thu, 2004-10-28 at 19:29, William Hooper wrote:
> D. D. Brierton said:
> [snip]
>
>> 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).
>
> 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]
>> 6. 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
3:10 p.m.
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 darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
3:31 p.m.
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.
--
William Hooper
4:37 p.m.
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]
>>
>>> 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).
>>
>> 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]
>>> 6. 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.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
6:41 p.m.
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
3:53 p.m.
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 Autodidact, curmudgeonly codger learning linux
Remember I know precious little of what I'm talking about!
9:03 p.m.
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".
--
William Hooper
1:12 p.m.
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.
--
Beartooth Autodidact, curmudgeonly codger learning linux
Remember I know precious little of what I'm talking about!
5:15 p.m.
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 ;)
--
Douglas Furlong <douglas.furlong(a)firebox.com>
10:08 a.m.
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 Autodidact, curmudgeonly codger learning linux
Remember I know precious little of what I'm talking about!
3:45 p.m.
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.
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
4:03 p.m.
New subject: SCSI problems.. [Some thoughts about yum and repositories]
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(a)ksu.edu
Phone: (785) 532-6072
Chemistry Department
Kansas State University
Manhattan, KS 66506-3701
9:31 a.m.
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
4:17 p.m.
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.
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
ge, Dublin 2, Ireland
2:14 a.m.
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.
--
Michael <mogmios(a)mlug.missouri.edu>
http://kavlon.org
7:22 a.m.
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,
--
Rodolfo J. Paiz <rpaiz(a)simpaticus.com>
8:57 p.m.
William Hooper wrote:
D. D. Brierton said:
[snip]
>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).
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.
7:15 a.m.
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/
--
William Hooperfe
1:51 p.m.
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 to
Livna.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 I
am
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 the
command
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 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.
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?
2:34 p.m.
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 to
> Livna.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 installed
No. 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 I
> am
> 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 the
> command
> 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 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.
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 darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
5:26 p.m.
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
markku.kolkka(a)iki.fi
5:40 p.m.
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...
--
Markku Kolkka
markku.kolkka(a)iki.fi
3:26 a.m.
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(a)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
Systems Administrator
Firebox.com
T: 0870 420 4475 F: 0870 220 2178
7:19 a.m.
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.
--
William Hooper
8:21 a.m.
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:
rpm -i http://my.new.repo.com/repo-blah.noarch.rpm
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
Systems Administrator
Firebox.com
T: 0870 420 4475 F: 0870 220 2178
9:15 a.m.
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.
--
Robin Laing
12:37 a.m.
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 to
> Livna.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 I
> am
> 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 the
> command
> 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 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.
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...
2:10 p.m.
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
2:45 p.m.
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.
--
Beartooth Autodidact, curmudgeonly codger learning linux
Remember I know precious little of what I'm talking about!
3:20 p.m.
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.
--
Robin Laing
3:28 p.m.
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 darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
4 p.m.
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. :)
--
Robin Laing
4:20 p.m.
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
--
=====================================================================
D. D. Brierton darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
7113
days inactive
7120
days old
35 comments
15 participants
participants (15)
-
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