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=2.7 required=5.0 tests=DATE_IN_FUTURE_03_06, DMARC_MISSING,MAILING_LIST_MULTI,RDNS_NONE autolearn=no autolearn_force=no version=4.0.0 Received: from saturn.prosalg.no (unknown [213.236.139.233]) by chiba.3jane.net (Postfix) with ESMTP id C2852200A98F for ; Thu, 7 Feb 2002 10:20:36 -0600 (CST) Received: from karltk by saturn.prosalg.no with local (Exim 3.33 #1) id 16YuCQ-0004gi-00 for gentoo-dev@gentoo.org; Thu, 07 Feb 2002 20:27:14 +0100 Date: Thu, 7 Feb 2002 20:27:14 +0100 From: Karl Trygve Kalleberg To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] The future of eclasses Message-ID: <20020207192714.GC17958@prosalg.no> References: <0GR400J6PPVFW3@mxout1.netvision.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0GR400J6PPVFW3@mxout1.netvision.net.il> User-Agent: Mutt/1.3.25i 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: 84ede4a9-f8b8-4085-b7f8-37ebc1a4baa1 X-Archives-Hash: d1bd3ec613f2b52e32d1a546f58a4a21 > 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