On 8/16/2012 4:59 AM, Rich Freeman wrote:
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.
tldr: I like, approve and otherwise +1 the idea of somehow paring down
or eliminating @system but I think it's going to be fairly challenging,
so more discussion on this topic is warranted in my humble non-developer
opinion :)
--
I really like everything you have to say here. Unfortunately,
assumptions of toolchain availability have gotten into the DNA of Gentoo
in ways that make it nontrivial -- although probably not rocket science,
either -- to implement these ideas.
I'd say it's the kind of thing where somebody needs to do the work. I
think there is demand for this, but when it comes down to brass tacks,
people who really need features like this can just write a script to
push some tarballs or files around in a way that's "good enough" for
their purposes. What is the cost/bene for a single sys-admin to do all
the work and politics of making this change?
However, staying with the cost/bene theme, we have here a kind of
externality, as they say in economics, (which is a fancy way, I guess,
of saying a bad decision or a raw deal), because, in the aggregate, I
think it's pretty clear that the cost/bene favors doing that work.
To be clear, I don't have religion about getting rid of @system, per-se,
but I do have religion about the stuff Larry the Cow told me when I
first visited the Gentoo homepage in 2001, or whenever, which was,
basically, that the software I was using had a bunch of frobs that I
couldn't touch, because I was running an rpm- or .deb-based system, and
that Gentoo was going to let me frob them.
It's not a total disaster, even now -- a determined sysadmin can
absolutely do this right now with features like prefix, ROOT, binpkg and
so forth.... but /really/ fixing this, so that non-standard/minimal
setups "just work", would allow Gentoo to effectively address a whole
bunch of really practical, real-world use-cases -- use-cases Gentoo is
in many aspects uniquely suited to address, due to Larry the Cow's
brilliant insights -- yet, by-and-large, due to precisely this @system
thing and the package-management decisions that have stemmed from it,
for which Gentoo has become unsuitable or impractical.
Specifically, I'm talking, here, about managed LAMP servers, big-data
clusters, and embedded.
I suppose I'm not doing much to fix it by ranting and raving like this
however. So see first paragraph :)
-gmt
