smaaaall gentoo

[meyerm]

Hi out there,

I've got several old PCs with small harddrives. For the complete system (including user files, spools etc), there are no more than 400 MB... Now I would like to know, how I can get my Gentoo smaller. I'm currently setting up an gentoo on a spare partition on my working PC. When it works (with syslog, webserver, qmail etc) I would like to move it onto one of the old PCs.

But what can I delete without danger? First: the kernel sources. OK. Then I will delete everything in /usr/portage/distfiles. But what about everything else in portage (despite special dir like "profiles")? Will I still be able to install new software precompiled on my working PC with emerge (using tbz2s)?

And how about all those locales which I will never ever use *g*. Finally I wouldn't need a GCC either. Can I remove it without problems?

Thanks,
Marcel

[phong]

You may want to see this howto on how to not install unused locale information.
_________________
"An empty head is not really empty; it is stuffed with rubbish. Hence the difficulty of forcing anything into an empty head."
-- Eric Hoffer

[klieber]

Well, the portage tree, even without any distfiles, is about 100MB, so you'd save quite a bit of space if you could mount that as an NFS share instead of having a local copy on every machine.

--kurt
_________________
The problem with political jokes is that they get elected

[rac]

[AutoBot]

You can also remove files in /var/tmp/portage/* as this sometimes can grow very large with failed ebuilds.
_________________
This message self destructed a long time ago.

[rdirmeyer]

gcc happens to be a pretty essential part of the ebuild system. If portage packages came pre-compiled, there would be no need for portage at all. The bz2/tbz2 files are collections of headers/source and other necessary components to build the package, they are not pre-compiled.

ebuilds are just build scripts that are customized for each package. The ebuild/portage system very much relies on being able to build packages locally, so removing gcc pretty much takes "emerge <blah>" out of service.

[meyerm]

Thanks for all of your answers.

@rdirmeyer
You're absolutely right, when it comes to source packages. But I ment already precompiled ones. Perhaps I wasn't clear enough or you don't yet know this nice feature of emerge - in the latter case I'd like to explain it to you (if we just misunderstood each other ignore this post )

Whenever you compile a new package out of the sources with "emerge -b <package>", portage configures and compiles the program. But it installs it into a "fake-root", say it creates a new directory-tree in an empty tmp. When everything is compiled and installed without errors, portage moves the content of this dir into the "real /". But when you enabled the "-b" switch, it creates a bzip2-compressed tar archive of this temporary tree and puts it in /usr/portage/packages before merging into the real /. Therefore, whenever you want to reinstall this package without changing any config (f.ex. a new installation of your system or on a similar other PC) you can install it with "emerge -k <package>" and portage search for this package before downloading the source. If it finds this package, it just unpacks it into the tree, registers the program to the portage-dbs and - that's it.

You see, why I thought I could perhaps even unemerge gcc? It is only needed on my host/working PC but not on the one, where the package is to be installed. Well, at least I hope so...

Phew, hopefully this is sth. new for you and I didn't just waste time and many keystrokes

[rdirmeyer]

i had a feeling i'd get a response like that... and i'm glad i did. no, it certainly wasn't a waste of keystrokes.

you are correct, i have never used that feature. you can bet i'll be playing around with it now, though. that's very cool. i appreciate your willingness to point this out to me; it's a great help! thanks!

-rd

[meyerm]