[gentoo-dev] Re: The future of ebuild

[Steve Long]

Felipe Contreras wrote:

> On Sat, Feb 23, 2008 at 10:45 PM, Alec Warner <antarus@g.o> wrote:
>> On 2/20/08, Felipe Contreras <felipe.contreras@×××××.com> 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@l.g.o mailing list