public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Chris Gianelloni <wolf31o2@gentoo.org>
To: Stewart Honsberger <blkdeath@gentoo.org>
Cc: Zack Gilburd <klasikahl@gentoo.org>, gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] New feature proposition (make.conf)
Date: 21 Aug 2003 05:19:51 -0400	[thread overview]
Message-ID: <1061457591.412.108.camel@vertigo> (raw)
In-Reply-To: <3F444E21.6060306@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]

On Thu, 2003-08-21 at 00:44, Stewart Honsberger wrote:
> Zack Gilburd wrote:
> 
> > One of the problems that plagues Gentoo is that the distro's growth is leading 
> > to an insane amount of distfiles downloads (and even excessive downloads) 
> > along with excessive rsync'ing.  Automatic removal of distfiles would 
> > substancially increase the amount of distfiles downloads due to the fact that 
> > packages often have revisions made to them and revisions mean that the 
> > software has to be recompiled -- thus the distfile would have to be 
> > redownloaded of already removed.
> > 
> > Until the general downloading (and rsyncing) etiqutte improves, I don't see 
> > how this could be The Right Thing(TM) to do.
> 
> I've been thinking along the lines of a cronjob being pulled in with, 
> say, Portage. Said cron job would, on a daily/weekly basis remove old 
> distfiles based upon age, and perhaps even have a setting to consider 
> size. (Eg; always/never remove files greater/less than a certain size).
> 
> That's where it gets tricky. OpenOffice, Mozilla et al. are two great 
> examples of packages whose source tarballs are *LARGE*. On one hand, 
> those would, in one fell swoop, free up the most HDD space = most 
> benefeit. On the other hand, they'd also cost more bandwidth to 
> re-download = most detrimental.
> 
> Operating on a strictly age-based system based around file access time 
> could potentially work, except that Gentoo's install defaults and/or 
> suggests strongly the notion of 'noatime' in fstab entries.
> 
> The script for the cronjob is easy, especially if it's only date-based. 
> The politics involved in implementing it, however, could be hairy. I'll 
> throw my script out there for review if it interests anybody and let 
> someone who's more proficient in Bash scripting add in the filesize details.

I use a script which deletes any files in distfiles which do not belong
to an installed package.  This keeps old packages out of my distfiles,
but also allows me to keep enough distfiles locally to keep from
hammering the mirrors constantly.  I think possibly a combination of the
two should be in order?  Maybe remove all non-installed distfiles on a
weekly basis and also remove all distfiles that have not been accessed
in something like 90 days?  This would keep things around long enough to
probably make it through any revision changes but also manage to clear
up room for the people that are complaining about space.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2003-08-21  9:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-17  9:45 [gentoo-dev] New feature proposition (make.conf) Philippe Lafoucrière
2003-08-17 11:06 ` Zack Gilburd
2003-08-17 11:17   ` Jason Wever
2003-08-17 11:59     ` Philippe Lafoucrière
2003-08-18 12:38       ` Chris Gianelloni
2003-08-18 18:51         ` Mike Frysinger
2003-08-18 19:23           ` Chris Gianelloni
2003-08-17 13:34     ` Dewet Diener
2003-08-21  4:44   ` Stewart Honsberger
2003-08-21  9:19     ` Chris Gianelloni [this message]
2003-08-21  9:43     ` Toby Dickenson
2003-08-28 16:06     ` Anders Eriksson
2003-08-28 16:25       ` Lisa Marie Seelye

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1061457591.412.108.camel@vertigo \
    --to=wolf31o2@gentoo.org \
    --cc=blkdeath@gentoo.org \
    --cc=gentoo-dev@gentoo.org \
    --cc=klasikahl@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox