Old kernel RPMS

Otto Haliburton ottohaliburton at comcast.net
Sun Mar 13 19:08:17 UTC 2005



> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-
> bounces at redhat.com] On Behalf Of Paul Iadonisi
> Sent: Sunday, March 13, 2005 12:59 PM
> To: Development discussions related to Fedora Core
> Subject: Re: Old kernel RPMS
> 
> On Sun, 2005-03-13 at 13:36 -0500, Ivan Gyurdiev wrote:
> 
> [snip]
> 
> > I don't see why this question is so inappropriate and irrelevant for
> > this list. In fact, it seems highly relevant to me, and I think
> > there should be a policy to keep backup versions of rpms in a
> > centralized place. I have needed such a thing on many occasions to
> > determine what was broken, or recover my system from a horrific crash,
> > due to Rawhide.
> 
>   I'm afraid I have to agree with Ivan here, Jeff.  This is most
> definitely *highly* relevant to this list.
>   I've never mentioned it myself before, but I have been meaning to
> bring it up.  I'm sure hoping it doesn't start a flamewar or anything,
> but I do think it's important to bring up.  The discussion belongs here,
> IMO, and not on fedora-test because it also applies to updates for
> released versions.
>   What I'm referring to is the relatively quick disappearance of
> previous updates, as well previous versions from rawhide.  A concern
> I've had about official updates disappearing, at least with respect to
> GPL/LGPL licensed software, is that these older updates should be made
> available for as long as the GPL requires (3 years?).  Currently, they
> disappear when new updates show up (or shortly thereafter).
>   I wouldn't worry about the licensing issue too much with rawhide given
> that it is 'in development' stuff, but it's still a bit extreme, IMO,
> for previous versions to disappear from the download.fedora.redhat.com
> immediately on appearance of the next version.
>   I'm not naive, here: I do know that keeping two or three versions
> around means significant disk space concerns, not just for Red Hat, but
> for all the mirrors.  Maybe a separate tree that a maximum of three
> versions could be maintained and instead of the rawhide update mechanism
> doing 'rm <rpm>', it could do 'mv <rpm> <backupdir>/<rpm>'.  Mirrors can
> choose to mirror the backup dir or not.
>   That's simplified of course, but I'm trying to promote some discussion
> of this.  It's burned me more than once.
> --
well, my 02c is to get rid of the list police, the time spent on what is
appropriate for the list and what is inappropriate for the list is as big a
waste of bandwidth as the original thread.  If a response is made to an
inquiry then it is appropriate otherwise it will die as all threads
eventually do.  Now see, I've wasted bandwidth by making my response.




More information about the fedora-devel-list mailing list