Subject: Re: Expiring old pkgsrc binaries
To: None <firstname.lastname@example.org>
From: Havard Eidnes <he@NetBSD.org>
Date: 07/13/2007 22:46:33
> > Remember, you can (almost) always recreate the old bits from source=
> While that is true, I do not believe this is entirely feasible under =
> circumstances. You do not want to be forced to compile any package on=
> old m68k system, for example. Cross-compiling is a partial solution,
There's hardly any m68k binary packages on our ftp server,
probably due to the pain in getting them built, as you allude
to above; all we have is
which is "partial only" by any measure.
However, during the initial cleanup, this one will *not* be
removed, even though the binaries are very old in pkgsrc terms --
the initial policy is "keep the two most recent directories".
It's only under the later policy (if it is agreed upon) that
we'll start removing package binaries based on their actual age,
and only keep the binaries for the previous and current branches.
So far cross-compiling is not really supported by pkgsrc, perhaps
first and foremost because many original package authors fail to
make a proper distinction between host and target (i.e. "not
first and foremost our fault")...
> > As I said, the NetBSD project's space for ftp is not infinite,
> > and with 5GB+ for each near-complete collection of binary
> > packages for a given arch+os+branch combination, this tends to
> > add up to quite a bit.
> What is the total amount of data? Perhaps I can arrange hosting.
The total size of the binary package directories we have
available on ftp.netbsd.org are at present
babylon5% du -sh packages*
However, at the moment the file system has only around 9GB free
space, so in order to make room for the 2007Q2 packages, we will
need to remove the old cruft soon, probably as early as on this
Frankly, I don't understand why anyone would want to install old
pkgsrc binaries, especially when new ones are available for the
same os-release / architecture combination. Some of the prime
candidates for pruning can be found in this partial report: