Hello all,
Over the past few months I have begun using new features in yum that support creating local repos that contain a mix of metadata from various upstream repositories without actually hosting the upstream packages. The general method of doing this is described here:
http://skvidal.wordpress.com/2009/08/04/creating-a-repo-of-arbitrary-pkgs-at...
So I can snag a few needed RPMs from EPEL, other upstream repos, and locally hosted RPMs to create one repository for users to configure and get all the bits they need for a particular purpose. This has worked great until recent EPEL updates landed and I discovered that EPEL does not retain any non-current RPMs in its repositories. That instantly breaks the "local" repository metadata that contains links to upstream packages that have been removed.
By keeping even just one previously released version of the package in the EPEL repos there could be a smooth transition for repos like mine. I suspect as things develop over time more people will be constructing repos in this fashion.
A second observation about the current state of the EPEL repos is that if an EPEL update causes things to break and needs to be reverted it is much easier for all involved if at least the previous version of the package remains in the repo to be used for a downgrade by the user of the repository.
For these reasons I'd like to request that EPEL adopt a repository policy that better support features of yum in use today and that makes recovery from the inevitable but rare occasions where downgrades are required by the end user simple. Keeping one or two previous versions of packages would accomplish both I think.
Thanks, John
I completely agree. I thought we did keep 1 version back, but perhaps I am wrong on that. +1 on making this an official stance for keeping at minimum 1 previous version.
Is this difficult to change from a technical perspective?
stahnma
On Tue, 2009-12-22 at 12:55 -0600, Michael Stahnke wrote:
I completely agree. I thought we did keep 1 version back, but perhaps I am wrong on that. +1 on making this an official stance for keeping at minimum 1 previous version.
Is this difficult to change from a technical perspective?
Yes, you'd need significant changes in mash to support this, or you'd need to write a post-mash utility that merged the new tree and parts of the old tree together, potentially re-making repodata. It is not a simple/easy task.
On Tue, Dec 22, 2009 at 12:11 PM, Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-12-22 at 12:55 -0600, Michael Stahnke wrote:
I completely agree. I thought we did keep 1 version back, but perhaps I am wrong on that. +1 on making this an official stance for keeping at minimum 1 previous version.
Is this difficult to change from a technical perspective?
Yes, you'd need significant changes in mash to support this, or you'd need to write a post-mash utility that merged the new tree and parts of the old tree together, potentially re-making repodata. It is not a simple/easy task.
So is the feature that inode0 is seeing a side-effect of koji usage versus plague (eg it worked when we were using plague but it changed when we went to koji?) I am not looking to go back to plague.. but wanting to pin down why/when the change occurred.
On Tue, 2009-12-22 at 13:53 -0700, Stephen John Smoogen wrote:
So is the feature that inode0 is seeing a side-effect of koji usage versus plague (eg it worked when we were using plague but it changed when we went to koji?) I am not looking to go back to plague.. but wanting to pin down why/when the change occurred.
When we moved from plauge to koji is when we went to exactly one copy of any package in the repo at any time.
On Tue, 22 Dec 2009 11:11:05 -0800 Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-12-22 at 12:55 -0600, Michael Stahnke wrote:
I completely agree. I thought we did keep 1 version back, but perhaps I am wrong on that. +1 on making this an official stance for keeping at minimum 1 previous version.
Is this difficult to change from a technical perspective?
Yes, you'd need significant changes in mash to support this, or you'd need to write a post-mash utility that merged the new tree and parts of the old tree together, potentially re-making repodata. It is not a simple/easy task.
I took a quick look at mash today.
It seems mash asks koji for the latest package in the indicated tag, and then uses those to build it's repo. There is support in koji to get all packages tagged in a tag, but then we would need some way to sort out only the most recent two from that list (if there are more than 1).
This could result in a issue if a new build was tagged, then another one before the first was pushed, then our repo wouldn't really have the previous version, just 2 newer ones.
Another approach we could try is to somehow hook it in around when it would do drpms (of course epel doesn't do them, but the code is there in mash). Have it copy the previous one there since it needs to find it anyhow to generate the drpm. Just have it copy that previous one at the same time.
Perhaps we could ask notting how much work/which approach would be most likely to be acceptable to mash upstream here?
I think it would be very nice to have the previous version around so we can do somewhat gracefull downgrades.
kevin
kevin
On Thu, 24 Dec 2009, Kevin Fenzi wrote:
On Tue, 22 Dec 2009 11:11:05 -0800 Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-12-22 at 12:55 -0600, Michael Stahnke wrote:
I completely agree. I thought we did keep 1 version back, but perhaps I am wrong on that. +1 on making this an official stance for keeping at minimum 1 previous version.
Is this difficult to change from a technical perspective?
Yes, you'd need significant changes in mash to support this, or you'd need to write a post-mash utility that merged the new tree and parts of the old tree together, potentially re-making repodata. It is not a simple/easy task.
I took a quick look at mash today.
It seems mash asks koji for the latest package in the indicated tag, and then uses those to build it's repo. There is support in koji to get all packages tagged in a tag, but then we would need some way to sort out only the most recent two from that list (if there are more than 1).
This could result in a issue if a new build was tagged, then another one before the first was pushed, then our repo wouldn't really have the previous version, just 2 newer ones.
Another approach we could try is to somehow hook it in around when it would do drpms (of course epel doesn't do them, but the code is there in mash). Have it copy the previous one there since it needs to find it anyhow to generate the drpm. Just have it copy that previous one at the same time.
Perhaps we could ask notting how much work/which approach would be most likely to be acceptable to mash upstream here?
I think it would be very nice to have the previous version around so we can do somewhat gracefull downgrades.
One logistical issue (not so much for EPEL at the moment but if Fedora follows suit with this) is mirror space. AFAIK for all of EPEL we're now doubling our requirements on the mirrors. We sort of have this unspoken agreement with the mirrors to keep all of Fedora and all of EPEL under 1T. Doubling EPEL right now would bring it to 46G. Not a big deal now but as EPEL grows, that grows, and as Fedora grows we reach that 1T mark.
-Mike
epel-devel@lists.fedoraproject.org
-
Howard Johnson -
inode0 -
Jesse Keating -
Kevin Fenzi -
Michael Stahnke -
Mike McGrath -
Stephen John Smoogen