From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JTWwr-0004K7-TO for garchives@archives.gentoo.org; Mon, 25 Feb 2008 06:36:26 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 74CE2E0427; Mon, 25 Feb 2008 06:36:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1B39EE0427 for ; Mon, 25 Feb 2008 06:36:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id ACCA265AD2 for ; Mon, 25 Feb 2008 06:36:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 required=5.5 tests=[AWL=-0.479, BAYES_05=-1.11, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-kfSQMvzIp0 for ; Mon, 25 Feb 2008 06:36:17 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id AB7DF678B7 for ; Mon, 25 Feb 2008 06:36:14 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JTWwV-0001kv-MH for gentoo-dev@gentoo.org; Mon, 25 Feb 2008 06:36:03 +0000 Received: from 82.152.218.215 ([82.152.218.215]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Feb 2008 06:36:03 +0000 Received: from slong by 82.152.218.215 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Feb 2008 06:36:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: The future of ebuild Date: Mon, 25 Feb 2008 06:43:50 +0000 Message-ID: References: <94a0d4530802201240v19dde77vff199cb11ece0bbd@mail.gmail.com> <94a0d4530802240353w1742c81dubcd01be1eee573a0@mail.gmail.com> 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.218.215 User-Agent: KNode/0.10.5 Sender: news X-Archives-Salt: 9cc4ff27-a654-4e25-9d8f-b0ba6f8a47c6 X-Archives-Hash: 02ab4315eb049dd9e7bf3b14ea3d2343 Felipe Contreras wrote: > On Sat, Feb 23, 2008 at 10:45 PM, Alec Warner wrote: >> On 2/20/08, Felipe Contreras wrote: >> > b) Error are difficult to handle since bash doesn't have exceptions >> >> I disagree here: most errors are fatal anyway any non fatal errors can >> be printed and saved via the elog facility. > > Yes, for the most common usage that's true, but that think about this > example: I'm compiling gstreamer-plugins-good, which needs libraw1394, > but the compilation fails, perhaps that user is not interested in that > particular plugin so a dialog can pop up and the user can choose if to > continue without the libraw stuff or fail. > That would typically be configured via USE flags, or for some things via a USE expand, like CAMERAS for gphoto. I agree there is scope for UI work, but I think that's better done by other apps calling the package manager, in the same way as other distros do. For Gentoo, we use update from the CLI, and himerge for a GUI, although portato (GTK) and kuroo (KDE) are both nice too. Typically in such an instance a user would see the package fail, and try with a different USE setting. We're adding USE editing to update, should be done this week; for all the GUIs that's already possible. In terms of what you're discussing, the package manager has to be able to run without user interaction, but a next generation build system is possible (eg pbuilds in python have been discussed on IRC, and qmake et al are around); ebuild is more a meta-format in that it can use a wide variety of base tools. update: http://forums.gentoo.org/viewtopic-t-546828.html http://www.haskell.org/himerge/ http://portato.origo.ethz.ch/ http://kuroo.org/ > I'm sure that can be done without exceptions but as the complexity > increases properly checking/passing around error values/messages > becomes tedious. > >> > c) Persistent information is difficult to achieve (no database stuff) >> >> How is this a bash limitation? Most languages don't have 'database >> stuff' built in. >> I don't see how saving stuff to files is much different than the env >> dumping we do in bash? > > I guess it's mostly the burden of serializing/parsing all that stuff. > Saving to flat files or databases gives the same persistence, and in any case the ebuilds don't mess around with them, the package manager does. It's perfectly possible to use a database to store the information ofc, but at some point you have to deal with the fact that ebuilds are text files edited by humans. >> > A more featured language could allow for example: filtered output, >> > exception handling->state storage->resuming. >> > Portage does all those at the moment (filtering output can easily be done by script, see update, or in an app like kuroo.) >> > But the big deal is with the package definition, recently I learned >> > about Domain Specific Languages, and I think that is the best option. >> > >> > A new dsl allows many interesting features in the package definition >> > itself like: inheritance, exceptions, arrays, hash tables, objects, >> > modules, documentation, information messages, etc. >> >> Note that most languages allow for the same things...so why would we >> author our own language? What runtime would it use? > > The language can be something very simple that has bash embedded. That > has the advantage that you can just copy paste what you are doing > already. > If it's got bash embedded it won't be simple ;) I see ebuilds as already providing that DSL, in that you have full BASH capability and a library of API functions you can use. >> > I've tried different build systems: rpm, dpkg, autopackage. >> > Unfortunately I never tried ebuild because it was based on bash as >> > far as I could tell. >> >> Typically a 'build system' would refer to 'autotools' or 'ant' or >> 'setuptools' not an ebuild. > > Is there such a big difference? > > I'm sure it's possible to by-pass autotools and write down all the > commands required to build something in an ebuild. Similarly it's > possible to use autotools to compile and install a bunch of packages. > You seem to be missing that ebuild is a support metastructure on top of build systems like make, autotools or distutils? > Those "build systems" also need to be updated, but that's another story. > What for? >> > After almost a decade of using Linux I still haven't found a build >> > system that suits all my needs. AFAIK ebuild is the most advanced but >> > it's still relying on ancient technology (bash scripts) so there will >> > always be limitations despite the brilliant ideas. >> >> Bash is not 'ancient' and it works suprisingly well for the vast >> majority of cases. I realize using a high level language would >> probably make some tasks easier (mmm dicts and real arrays). There is >> the matter of porting over 10000 ebuilds however ;) > > Yeah, bash is pretty good for many things, just doesn't scale that much. > I'm not sure where and how it needs to scale. The API provided is very easy to work with and encompasses an amazing range of build systems. > At some point someone decided the current status was not good enough > and decided to create ebuild, even though he was well aware that > thousands of already existing instructions about how to build packages > would have to be re-written. > Not at all; ebuild utilises those instructions (eg makefiles). It just makes every build system available and provides an extended BASH API for common tasks. > If it's easy to write people will possibly even write more of those. > Take for example ArchLinux which also has around 10,000 packages > simply because it's so easy to write them. > Ebuilds are pretty easy too imo. It's perfectly possible to write an ebuild without a single function, for example, if the standard configure --prefix=/usr and make system is in-place (and eclasses extend that to other systems.) > And with something that is distribution agnostic, different > communities can benefit from sharing the same rules. > Ebuilds and portage can be used elsewhere, see http://www.gentoo.org/proj/en/gentoo-alt/prefix/index.xml and in any case Gentoo can be, and is, used as a basis for a binary distro. >> > >> > The core of a distribution is the "packaging" system, and the core of >> > the packaging system is the building system, which has no reason not >> > to be distribution agnostic, and actually, packaging system agnostic. >> > >> > Why not create a new build system with a state of the art programming >> > language, and an advanced DSL that actually other distributions could >> > use? >> I personally don't see the need. -- gentoo-dev@lists.gentoo.org mailing list