Okay, I should probably have separated these suggestions into their own bug reports, but it'd perhaps be best for you to organise them as you see fit. These size tweaks are mostly aimed at embedded systems, and very small/old pc installations (gateways, firewalls, bridges with small harddrives, or compact flash cards or whatever that's substantially smaller than 1GB). 1) It'd be nice if we could turn off the use of /var/cache/edb; on smaller systems, size is more important than installation speed. Same goes with /usr/portage/metadata 2) Is there any way we can compress the contents on /usr/portage ? On my machine, the checked out CVS tree takes about 128MB, as reported by du -h. A zip file of the same takes 17.5MB, so there are substantial savings to be made (it should be even somewhat smaller if I removed all the CVS directories). I'd be willing to try writing a Portage version that worked on a .zip file instead of a directory tree. 3) It'd be nice to say that I don't want any man pages, any info pages, any localisation, so that Portage at the central level would ignore any files going into /usr/share/man, /usr/share/info and /usr/lib/locale, respectively (of course, we'd probably like to ignore based on MANPATH, INFOPATH and LOCALEPATH or something similar. Perhaps this could just be an IGNOREPATH for now, so that I could easily add paths I don't want stuff put into, based on the system I'm building ? One alternative would be for every package to have an info, a man and a doc useflag, which is very error-prone, IMHO. 4) Perhaps /var/db/pkg could be compressed also ? There's less to be had here (5MB compressed, 35MB uncompressed, 405 installed packages). However, if we bothered with a compressed database in the first place, the coding work should be easy enough. This is all aimed at small systems (<1GB persistent storage), not tiny, embedded stuff. We shouldn't expect to do compilation and installation on the ipaq with a grand total of 64MB RAM, for instance :)
i really like #3 ;) on some systems i just rm -rf those dirs after i do an emerge ...
The space problem results from filesystem overhead mostly, a du -sh /usr/portage gives >200 MB, the concatenated content is <50 MB. Removing the metadata doesn't help much. Just one more reason for a DB backend.
#3 can be covered by MERGE_EXLCUDE (or whatever it will be called finally) for the other point it would be interesting to see how a compressed loopback filesystem for /usr/portage, /var/db/pkg and /var/cache/edb/ affects the size.
About point #1: - excluding /usr/portage/metadata from the sync is already possible by adding the path to your rsync exclusion file (see RSYNC_EXCLUDEFROM in make.conf). Removing its content once for all doesn't hurt, and it would not be filled any more. Also, for instance for a firewall, excluding some categories (kde-*, gnome-*, x11-*, etc.) would probably help. - for /var/cache/edb/cache, I think (but I've not tried) that mounting this dir on some kind of temporary ram disk may be a solution: You would that way do the caching work only once (otherwise, it will be done several time for a single emerge, plus one for the "emerge -p", etc.), but wouldn't use any disk space. I don't know this things well though, for instance, is there a way to limit the virtual disk size, by forcing it to delete the oldest files when needed? Well, at least the idea deserves some experiments.
#1 I'm not much for (w/out the cache, portage is quite slow). Implementing #2 will be a pita. Personally I'd just abuse a compressed loopback. Option 3 has been implemented; Option 4 won't be compressed, although the # of files will likely be cut down at some point (move to a single file, rather then dozen).
Slapping this one shut... the issues raised/mentioned are being dealt with seperately via the embedded effort, and ongoing portage-dev efforts. Mostly, no major specifics here, and it's a bit dead atm.
