Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Gregory M. Turner]

On 8/16/2012 4:59 AM, Rich Freeman wrote:
> On Wed, Aug 15, 2012 at 3:18 PM, Michael Mol <mikemol@×××××.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