public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Stewart Honsberger <blkdeath@gentoo.org>
To: Zack Gilburd <klasikahl@gentoo.org>
Cc: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] New feature proposition (make.conf)
Date: Thu, 21 Aug 2003 00:44:17 -0400	[thread overview]
Message-ID: <3F444E21.6060306@gentoo.org> (raw)
In-Reply-To: <200308170406.53791.klasikahl@gentoo.org>

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.

-- 
Stewart Honsberger
http://blackdeath.snerk.org/
"Capitalists, by nature, organize to protect themselves.
-- Geeks, by nature, resist organizaion."


--
gentoo-dev@gentoo.org mailing list


  parent reply	other threads:[~2003-08-21  4:44 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 [this message]
2003-08-21  9:19     ` Chris Gianelloni
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=3F444E21.6060306@gentoo.org \
    --to=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