RFC: cleaning up updates and updates-testing

Nifty Hat Mitch mitch48 at sbcglobal.net
Fri Sep 10 10:54:21 UTC 2004


On Thu, Sep 09, 2004 at 02:56:32PM -0400, Bill Nottingham wrote:
> Christof Damian (christof at damian.net) said: 
> > > At the moment, the Fedora updates tree is somewhat out of hand
> > > (look, wow - 27G).
> > > 
> > > Does anyone have any specific and concrete objections to removing
> > > older, superceded, updates?
> > 
> > I guess this is just meant for cleaning up the directory and not to
> > save space? I don't mind the cleanup, but would like the old updates
> > archived somewhere.
> 
> It's for both, actually.
> 
> Frankly, I see no need for archiving of:
> 
> a) old test updates
> b) test updates that have been superceded by final updates

Your mirror and rsync folks will like you for reducing the size
of the site.

Test updates old and superseded by a final package should have a short
life.

> Others, there could be some use for, I suppose.

For others a longer life makes sense.  Some new updates 
trigger troubles for some users and keeping the older
bits handy has value.

I should comment, IMO src rpms should have a longer life than the
binary.  With a src rpm bits can be rebuilt and differences inspected
for debugging things.

Rsync sites have control over the --delete function
so those that have the space can elect to keep old cruft
and remove it with a local policy.

Start with a simple straw man policy that has 
some potential of being automated and being done in
stages.

Something like:

 I. Test
   a) old test updates
   b) test updates that have been superseded by final updates

 will be moved to 'old-test' 7 days after a newer package is
 available. After 14 days they will be removed from 'old-test'.

 II. Released
   c) Superseded binary packages

 will be move to "Superseded Packages" 14 days after the general
 release of a newer version and removed after 30 days.  Src packages
 will be retained an additional 30 days.



-- 
	T o m  M i t c h e l l 
	Just say no to 74LS73 in 2004





More information about the fedora-list mailing list