[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Recent RPM retention in the EPEL repos



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]