From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=4.0.0 Received: from email.fidnet.com (ecomm2.fidnet.com [216.229.64.81]) by chiba.3jane.net (Postfix) with SMTP id E6F30200AD47 for ; Thu, 7 Feb 2002 11:45:07 -0600 (CST) Received: (qmail 3254 invoked from network); 7 Feb 2002 17:43:59 -0000 Received: from dialup-mo-61.rolla.fidnet.com (HELO silica.localmosci) (216.229.74.61) by email.fidnet.com with SMTP; 7 Feb 2002 17:43:58 -0000 Subject: Re: [gentoo-dev] The future of eclasses From: "Tod M. Neidt" To: gentoo-dev@gentoo.org In-Reply-To: <20020207192714.GC17958@prosalg.no> References: <0GR400J6PPVFW3@mxout1.netvision.net.il> <20020207192714.GC17958@prosalg.no> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 07 Feb 2002 11:43:37 -0600 Message-Id: <1013103818.15050.15.camel@silica.localmosci> Mime-Version: 1.0 Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 44566f67-4671-4463-9861-58f433536b81 X-Archives-Hash: 572162417a3c3ed6f4eb6f5f35563e70 Hi! My thoughts for what their worth: On Thu, 2002-02-07 at 13:27, Karl Trygve Kalleberg wrote: > > This is all almost certainly portage v2 stuff. However I'd like everyone > > working on portage (e.g. Bevin, with whom I've spoken) to know where we > > stand, to coordinate our efforts. As always, any ideas, forecasts, > > suggestions etc. are always welcome. > > I like the idea. If its documentation becomes part of the ebuild howto, > it will get adopted fairly quickly. I too find the concept of eclasses "sexy." Not being a KDE user my experience with them has been limited, but I do appreciate the motivation behind them. However, .... > > The main concern Hallski and me (and possibly others, such as John > Stalker, if memory serves) was that the current ebuild system mirrors > the manual build process so closely that external contributors have > little or no difficulty sending us ebuilds. The structure of ebuilds being analogous to the ./configure, make, make install manual build sequence is a tremendously valuable "feature" for gentoo users in my opinion. Holds to the "form follows function" principal and is relatively transparent to a user who wants to tweak an ebuild to suit their needs with minimal effort. I admit that I am an unabashed promoter of the KISS principal (one of my daily working mantras, along with "check the connections" :) Is their anyway that eclasses could be "hidden" in portage so that the visible ebuilds remains simple, i.e at least gives the appearance of being analogous to ./configure, make, make install? As John Stalker stated in another post, the ability to understand, or at least think you understand, with minimal effort what is happening when you merge a particular ebuild is attractive. > What plagues many non-kde ebuilds is that their build systems are fairly > non-standard. And even packages with seemingly standard build systems > quickly turn out to have both minor and major flaws (Mailman is a good > example of a horrible build system that on the surface looks nice, but > in practice turns out to be a real bitch). Many of the applications that I am interested in have roots in 30+ year old FORTRAN and have never even had a Makefile provide in the tarball. Yes, they are still of value, the kind that only 30+ years of peer review can provide. Again, I find the eclasses concept sexy. I am just concerned with what might be lost, especially by the Gentoo user, in their application. Has anyone tabulated an objective Advantages/Disadvantages analysis of eclasses? tod