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 Mail.Math.Princeton.EDU (mail.math.Princeton.EDU [128.112.18.14]) by chiba.3jane.net (Postfix) with ESMTP id 75CFE200A98F for ; Thu, 7 Feb 2002 10:53:03 -0600 (CST) Received: from fine1008.math.princeton.edu (IDENT:root@fine1008.math.princeton.edu [128.112.16.123]) by Mail.Math.Princeton.EDU (8.11.6/8.11.6) with ESMTP id g17GpuF16109 for ; Thu, 7 Feb 2002 11:51:56 -0500 Received: from fine1008.math.princeton.edu (stalker@localhost) by fine1008.math.princeton.edu (8.11.6/8.11.6) with ESMTP id g17Gpuu02944 for ; Thu, 7 Feb 2002 11:51:56 -0500 Message-Id: <200202071651.g17Gpuu02944@fine1008.math.princeton.edu> To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] The future of eclasses In-reply-to: <20020207192714.GC17958@prosalg.no> References: <0GR400J6PPVFW3@mxout1.netvision.net.il> <20020207192714.GC17958@prosalg.no> Comments: In-reply-to Karl Trygve Kalleberg message dated "Thu, 07 Feb 2002 20:27:14 +0100." Date: Thu, 07 Feb 2002 11:51:56 -0500 From: John Stalker 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: 93823375-cb38-440e-ac05-dd0635a45c69 X-Archives-Hash: cf7e3cc39365a5e9bd3b3587658517bd I agree with almost all of this, but I would like to add one additional point. It's not solely a matter of encouraging users to contribute ebuilds, but also of allowing them to understand them. I want to understand what will happen when I type emerge foo/bar before I actually do it. This is what always annoyed me about rpm and deb. There are two ways of dealing with this. One is to keep everything in a familiar format, ie bash for gentoo portage or Makefiles for FreeBSD ports, and the other is to have a stable well-documented interface to some mysterious black box. I would much prefer the former wherever it is feasible, but of course I don't have the burden of maintaining large numbers of ebuilds. > > 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. > > 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. > > I think this can be solved somewhat if it is clearly documented _what_ > is assumed by the various eclasses and perhaps a motivation when the > assumptions are less than crystal clear. > > 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). > > The minor nuisances of the various build systems mean that we might find > it easier to patch the generated Makefiles instead of the Makefile.in or > Makefile.am files, thus requiring an intermediate step between > configure and make (ie, patching in src_unpack is too troublesome). > > Consequently a simple wrapper for src_compile will only work a certain > percentage (possibly relatively low; <= 50%) of the time, and a > full-blown manual src_compile() function must be written for the rest of > the ebuilds. > > The situation for src_install() is even more dire, as it would appear > that close to all packages have trouble conforming to any kind of FHS, > and installing in a temporary directory is completely foreign. > > Now, for our regular ebuild writers, the 50% saving is a big deal. For a > new submitter, it means he has to figure out which eclasses are > available (+ what they are), which criteria his package must meet to be > able to avail himself of the various eclasses, and finally test that > this is really so. > In conclusion, I am very positive about eclasses for our regular > contributors; it would possibly give us yet another advantage to our > package system that would allow us to add more ebuilds more quickly (one > could argue that quantity in itself is not a good thing, and of course I > agree ;). But if our intention is that "regular" users should easily > be able to submit ebuilds, and more easily so than writing a debian > package or an rpm spec, then we must be very careful to consider the > result eclasses have on our "regular" users. > > > > Kind regards, > > Karl T > _______________________________________________ > gentoo-dev mailing list > gentoo-dev@gentoo.org > http://lists.gentoo.org/mailman/listinfo/gentoo-dev -- John Stalker Department of Mathematics Princeton University (609)258-6469