On Wed, Aug 15, 2012 at 3:18 PM, Michael Mol <mike...@gmail.com> wrote: > It also sounds like something like that could be a benefit to shrinking > @system. >
I think the solution to the circular dependency issue isn't to make Portage able to completely bootstrap the whole system, but rather just to make it capable of coping with the issues and knowing when to raise an alarm. Gentoo will always involve extracting a tarball/etc for the initial installation since you always need SOMETHING to start with. You can't even chroot into your install directory without a shell being there, and typing "emerge" won't go so well if portage isn't actually installed. So, continue to build stages like we do right now - no doubt with hard-coding and such to get around the dependencies. As far as objections to listing gcc and such in every ebuild go, why not? We list all kinds of routine stuff in hundreds of ebuilds so that we can install systems without them. Why not just have a toolchain virtual or something? And since ssh was brought up - this is what happens with hacks like this. When you combine the "default install" with the "minimum deps for everything" list you end up with an ssh you can't get rid of without the package.provided hack (which really should be used for stuff that is, well, provided). It would be nice if people who want to build a server with Gentoo but then reduce it to only true RDEPENDS could do so. Obviously they'd have to use binary packages to continue to maintain it (and even then they'd need to keep portage on it), or they'd have to build another one. Actually, the trend in general is towards disposable servers anyway so generating an entire new server every time one thing changes is probably a desirable thing, since you probably want to be able to do it every time you add a server anyway. Rich
