Karanbir Singh wrote:
> Troy Dawson wrote:
>> First: I figured I'd get a jump on RedHat. Version 3.0.3 has several
>> bugfix's over 3.0.0. I don't *know* that they are going to go this
>> version, but I would hope that they try to keep up to the latest
>> stable version. I don't think they will jump versions (like go from
>> 3.0 to 4.0) but I would hope they keep up with the latest track. (go
>> from 3.0.3 to 3.0.4)
>
> Fair enough, we are going to watch what upstream release with. I've got
> a few patches backported from 3.1 and 3.0.x - so depending on what they
> ship with, we might roll a few changes in from our own side - but we are
> unlikely to bump version right now and watch how their yum tracking
> goes. All the rhn code is separated into other pkgs, so the yum is
> mostly clean.
>
>> That depends on what the upstream vendor does. If they move along the
>> same track, keeping up with the latest bug fixes, then I will use theirs.
>> If they stick with yum 3.0.0, then no, I will just follow the yum's
>> stable track, as long as it doesn't break other items in the release.
>
> Do you intend to leave the rhn specific code in the distro ? apart from
> that, I dont think there should be a major issue. But we need to watch
> for that.
>
I still don't know.
We pulled all the rhn stuff out of the comps file, and it looks like
nothing depends on it. So it looks like it would be safe to actually
pull it out of the release.
But in the back of my mind I just know that if we pull all the rhn stuff
out of the release, someone is going to find a use for it.
But on the other hand, if we don't pull it out, somebody is going to
install it and then complain because it doesn't work, even though they
would need a RHN subscription to get it to work.
>> Two things to note.
>> We have been putting yum into Scientific Linux (and Fermi Linux before
>> that) for a long time. It is something I and Connie regularly track
>> and feel confident we will be able to continue to do so.
>
> Interesting, are you looking to bring in yum-3.x to SL-4 as well ? Its
> something we are interested in doing, if not - I am going to start
> seeing what parts of the functionality we might be able to backport to
> the yum-2.4.x tree that is right now in CentOS-4.
>
No, I was planning on letting SL 4's yum be somewhat frozen. I'm
debating on updating it to yum 2.6 to help with the kernel-module
plugin, but not many changes beyond that.
>> And, we have to change the upstream vendors yum anyway. I do not want
>> their RHN plugin in our yum. So yum will never come straight from
>> them unaltered.
>
> what did you need to change in the yum package ? it looks mostly clean
> to me as it is. We are still thinking about including fastestmirror and
> protectbase + priorities into the default install, but not decided as yet.
>
> - KB
We always have yum-conf be separate from yum. So that if a site want's
to have their own yum configuration, they don't have to worry about
messing with the main yum file, they can just change the yum-conf. We
also add the kernel-module, and hopefully I can get the final minor bugs
out of the merger of kernel-module and kmdl.
But beyond that, the other plugins and utils will be their own rpm's.
Actually, now that I think of it, Connie had mentioned putting
protectbase into the main one, and Jarek had talked about getting
fastestmirror in as well.
Connie isn't here, so I can't ask her her opinion right now, so we'll
have to get back to you on that.
I know, the only problem I have with fastestmirror is getting the
initial list of mirrors in a file.
Does anyone else have any opinions about which plugin's should be in the
base yum?
Troy
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
|
