Recent RPM retention in the EPEL repos

Kevin Fenzi kevin at tummy.com
Thu Dec 24 21:12:14 UTC 2009


On Tue, 22 Dec 2009 11:11:05 -0800
Jesse Keating <jkeating at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20091224/679fbc70/attachment.sig>


More information about the epel-devel-list mailing list