firstly, we slipped on shipping beta out yesterday, but we hit a couple of issues that needed to be resolved before we could get the iso's out. Most of the things are now fixed and the final bits are building as I write this email.
there is one issue that was raised by Johnny that really does need fixing, perhaps not something for beta-public, but something that does need to get fixed for Final release.
<background> The way things stand right now, anaconda uses yum in c5, so the media now contains a local repository metadata but its not the standard meta data used by yum. Anaconda and pirut need a specific string added in ( the mediaid fluffage, some of the fedora guys will be familiar with ) so that they can use the media at installtime and also be able to use the same media post install to add packages.
The issue is, that this now creates a problem in that you can no longer loop mount the DVD iso under a http/ftp server and just use that as a remote repository to pull packages from using yum. </background>
So now the thing is - for us to facilitate this there are three options.
1. We ship 2 repodata/'s on the media and use one for anaconda and use the other for yum ( ugly fix )
2. We change anaconda to not need that media stuff in the repodata/, and get that from somewhere else ( not gonna happen : too much work, and too much potential to change from upstream in ways not even imaginable )
3. We fix yum to use the media fluff'd repodata/ ( potentially a few lines fix and should just work ). This will allow yum + anaconda, pirut and friends to essentially just use the same repository metadata.
What does everyone else think about this ? I think from this email, my own personal preference is easy to make out.
Also, is this really an issue we even need to worry about ? For me, its an issue since I use loop mounted media right off the block. Does anyone else do the same, or is everyone just coping the tree's out and doing createrepo foo ?
On Thu, Mar 08, 2007 at 07:24:55PM +0000, Karanbir Singh enlightened us:
firstly, we slipped on shipping beta out yesterday, but we hit a couple of issues that needed to be resolved before we could get the iso's out. Most of the things are now fixed and the final bits are building as I write this email.
there is one issue that was raised by Johnny that really does need fixing, perhaps not something for beta-public, but something that does need to get fixed for Final release.
<background> The way things stand right now, anaconda uses yum in c5, so the media now contains a local repository metadata but its not the standard meta data used by yum. Anaconda and pirut need a specific string added in ( the mediaid fluffage, some of the fedora guys will be familiar with ) so that they can use the media at installtime and also be able to use the same media post install to add packages.
The issue is, that this now creates a problem in that you can no longer loop mount the DVD iso under a http/ftp server and just use that as a remote repository to pull packages from using yum.
</background>
So now the thing is - for us to facilitate this there are three options.
- We ship 2 repodata/'s on the media and use one for anaconda and use
the other for yum ( ugly fix )
- We change anaconda to not need that media stuff in the repodata/, and
get that from somewhere else ( not gonna happen : too much work, and too much potential to change from upstream in ways not even imaginable )
- We fix yum to use the media fluff'd repodata/ ( potentially a few
lines fix and should just work ). This will allow yum + anaconda, pirut and friends to essentially just use the same repository metadata.
What does everyone else think about this ? I think from this email, my own personal preference is easy to make out.
Also, is this really an issue we even need to worry about ? For me, its an issue since I use loop mounted media right off the block. Does anyone else do the same, or is everyone just coping the tree's out and doing createrepo foo ?
It will probably bite anyone using yam/mrepo, since it does iso loopback mounting.
I'm voting for #3, especially if it's something that could be accepted upstream that won't break anything else.
Matt
On Thu, 2007-03-08 at 14:34 -0500, Matt Hyclak wrote:
On Thu, Mar 08, 2007 at 07:24:55PM +0000, Karanbir Singh enlightened us:
firstly, we slipped on shipping beta out yesterday, but we hit a couple of issues that needed to be resolved before we could get the iso's out. Most of the things are now fixed and the final bits are building as I write this email.
there is one issue that was raised by Johnny that really does need fixing, perhaps not something for beta-public, but something that does need to get fixed for Final release.
<background> The way things stand right now, anaconda uses yum in c5, so the media now contains a local repository metadata but its not the standard meta data used by yum. Anaconda and pirut need a specific string added in ( the mediaid fluffage, some of the fedora guys will be familiar with ) so that they can use the media at installtime and also be able to use the same media post install to add packages.
The issue is, that this now creates a problem in that you can no longer loop mount the DVD iso under a http/ftp server and just use that as a remote repository to pull packages from using yum.
</background>
So now the thing is - for us to facilitate this there are three options.
- We ship 2 repodata/'s on the media and use one for anaconda and use
the other for yum ( ugly fix )
- We change anaconda to not need that media stuff in the repodata/, and
get that from somewhere else ( not gonna happen : too much work, and too much potential to change from upstream in ways not even imaginable )
- We fix yum to use the media fluff'd repodata/ ( potentially a few
lines fix and should just work ). This will allow yum + anaconda, pirut and friends to essentially just use the same repository metadata.
What does everyone else think about this ? I think from this email, my own personal preference is easy to make out.
Also, is this really an issue we even need to worry about ? For me, its an issue since I use loop mounted media right off the block. Does anyone else do the same, or is everyone just coping the tree's out and doing createrepo foo ?
It will probably bite anyone using yam/mrepo, since it does iso loopback mounting.
I'm voting for #3, especially if it's something that could be accepted upstream that won't break anything else.
- except that we've already fixed yum 3.1.X for this problem.
If you want to backport the patch from 3.1.x to 3.0.x that'd probably be simplest.
in fact, it's probably what red hat has done, too.
-sv
seth vidal wrote:
I'm voting for #3, especially if it's something that could be accepted upstream that won't break anything else.
- except that we've already fixed yum 3.1.X for this problem.
If you want to backport the patch from 3.1.x to 3.0.x that'd probably be simplest.
in fact, it's probably what red hat has done, too.
I didnt know redhat had fixed this issue...
Based on early info, the fix seems to be just a 3 line patch. However, I will go see what was done for 3.1.x
- KB
seth vidal wrote:
- except that we've already fixed yum 3.1.X for this problem.
If you want to backport the patch from 3.1.x to 3.0.x that'd probably be simplest.
in fact, it's probably what red hat has done, too.
I've got yum--3.0.x from c5b working with the mediaid stuff in a remote repo, took a part of the patch from jkatz - since he seemed to also be fixing other stuff in there.
but the plot got a bit dense from there on - since it now seems we need to either :
a) also backport that fix into yum-2.4 (!)
or
b) get a yum-3.0.x working on CentOS-4 so that people can grab that rpm, and use that to move from CentOS-4 to CentOS-5
I know the yum migration route isnt supported or even encouraged - but thats not going to stop people from doing it anyway ( as we saw during the CentOS-3 to CentOS-4 release time ). So if we can, I'd really like to make this possible, in some way or the other.
So, does anyone have the time to look at this ? I am quite tied up with a *lot* of stuff on my plate at the moment.
- KB
Karanbir Singh wrote:
seth vidal wrote:
- except that we've already fixed yum 3.1.X for this problem.
If you want to backport the patch from 3.1.x to 3.0.x that'd probably be simplest.
in fact, it's probably what red hat has done, too.
I've got yum--3.0.x from c5b working with the mediaid stuff in a remote repo, took a part of the patch from jkatz - since he seemed to also be fixing other stuff in there.
but the plot got a bit dense from there on - since it now seems we need to either :
a) also backport that fix into yum-2.4 (!)
or
b) get a yum-3.0.x working on CentOS-4 so that people can grab that rpm, and use that to move from CentOS-4 to CentOS-5
I know the yum migration route isnt supported or even encouraged - but thats not going to stop people from doing it anyway ( as we saw during the CentOS-3 to CentOS-4 release time ). So if we can, I'd really like to make this possible, in some way or the other.
So, does anyone have the time to look at this ? I am quite tied up with a *lot* of stuff on my plate at the moment.
FYI - Scientific Linux is using yum-3.0.3 and yum-metadata-parser-1.0.3 (newer than in RHEL5 Beta2). Maybe that will help. http://mirror.cpsc.ucalgary.ca/mirror/scientificlinux.org/5rolling/SRPMS/?C=...
Greg
- KB
Greg Swallow wrote:
So, does anyone have the time to look at this ? I am quite tied up with a *lot* of stuff on my plate at the moment.
FYI - Scientific Linux is using yum-3.0.3 and yum-metadata-parser-1.0.3 (newer than in RHEL5 Beta2). Maybe that will help. http://mirror.cpsc.ucalgary.ca/mirror/scientificlinux.org/5rolling/SRPMS/?C=...
its definitely worth asking them why :)
- KB
-
Greg Swallow -
Karanbir Singh -
Matt Hyclak -
seth vidal