From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 4F3A7138216 for ; Thu, 16 Aug 2012 19:53:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 87DA021C02C; Thu, 16 Aug 2012 19:52:54 +0000 (UTC) Received: from malth.us (malth.us [75.147.143.249]) by pigeon.gentoo.org (Postfix) with ESMTP id 184FBE078D for ; Thu, 16 Aug 2012 19:51:33 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by malth.us (Postfix) with ESMTP id 0D62740CB64B for ; Thu, 16 Aug 2012 12:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at malth.us Received: from malth.us ([127.0.0.1]) by localhost (malth.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjmTSUPq0xbQ for ; Thu, 16 Aug 2012 12:51:30 -0700 (PDT) Received: from [192.168.0.175] (moneypit.hq [192.168.0.175]) by malth.us (Postfix) with ESMTPSA id EB4B440CB8BF for ; Thu, 16 Aug 2012 12:51:29 -0700 (PDT) Message-ID: <502D4F41.9080608@malth.us> Date: Thu, 16 Aug 2012 12:51:29 -0700 From: "Gregory M. Turner" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Questions about SystemD and OpenRC References: <1344366029.24762.31.camel@TesterTop4> <502377E7.8010803@gentoo.org> <1344535966.2121.6.camel@TesterTop4> <20120809183130.GA6795@linux1> <20120809195727.5d04ccff@googlemail.com> <20120814032416.GA8489@kroah.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 1ea945f2-d9c4-4657-9d49-b8966907dd5a X-Archives-Hash: f725f2aa0112e1c171f69a965361ea0c On 8/16/2012 4:59 AM, Rich Freeman wrote: > On Wed, Aug 15, 2012 at 3:18 PM, Michael Mol 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