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 1JTFQS-0004Nx-IP for garchives@archives.gentoo.org; Sun, 24 Feb 2008 11:53:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C7856E03CC; Sun, 24 Feb 2008 11:53:46 +0000 (UTC) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by pigeon.gentoo.org (Postfix) with ESMTP id 93A3FE03CC for ; Sun, 24 Feb 2008 11:53:46 +0000 (UTC) Received: by wx-out-0506.google.com with SMTP id h30so2713750wxd.10 for ; Sun, 24 Feb 2008 03:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Ls3p560JyzRMH677YFzj1ybwVoGikR8tpBRIk1bodkU=; b=TUxa05rW3zIHn8+88WtcOY6sje+2GluylQ4TBgxpYAzBBt8i0opwQ77xl5PVdIWkRFnQv7rqwY6gv800dzY8SY0McEdkTLKb8eEJbypJx4g9ZAQXX8QB0TQTx7dybp5RjOZwPulZQ8A6D0PlmKdleLJ3cA0gCBQezXR7vOSDxyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mqezybVI4B9ceqTsZUyIqL/CVSZ3gslf+D8Ll3EYHhECzCPyAUYlrmp3nq77zD7nPGo6UZzWZ5A8/mYoy6d7GcD5vmiDw3tZpaweD+WL8Fgibwd78Bk3mx/px2uQnDTOwpiDU2r21ZOYOP7Eews3CIw100O6qDwFTiA9N3+lu9Q= Received: by 10.140.82.38 with SMTP id f38mr1024489rvb.30.1203854025393; Sun, 24 Feb 2008 03:53:45 -0800 (PST) Received: by 10.140.188.7 with HTTP; Sun, 24 Feb 2008 03:53:45 -0800 (PST) Message-ID: <94a0d4530802240353w1742c81dubcd01be1eee573a0@mail.gmail.com> Date: Sun, 24 Feb 2008 13:53:45 +0200 From: "Felipe Contreras" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] The future of ebuild In-Reply-To: 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=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <94a0d4530802201240v19dde77vff199cb11ece0bbd@mail.gmail.com> X-Archives-Salt: 2bf9d169-9931-478e-967f-abd991a1844c X-Archives-Hash: 26ff73e23cca50497e0e53ba6e14f940 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. 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. > > A more featured language could allow for example: filtered output, > > exception handling->state storage->resuming. > > > > 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. As more ideas appear the DSL can be updated, but still, the embedded bash would always be there. > > This is based on an already working prototype made in Ruby, so it's > > biased towards Ruby facilities. > > It looks Rakish ;) Perhaps, the only interesting thing here is that those commands are not defined internally. There's an auxiliary bash shell that is running those commands. Not like "system" calls, which loose the environment between calls, this is something that cooperates nicely. > > 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. Those "build systems" also need to be updated, but that's another story. > > 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. 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. 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. And with something that is distribution agnostic, different communities can benefit from sharing the same rules. > > > > 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 would talk to Drobbins, he was talking about something like this to > manage complexity. Will do. Best regards. -- Felipe Contreras -- gentoo-dev@lists.gentoo.org mailing list