Re: [gentoo-dev] The future of ebuild

[Alec Warner]

On 2/20/08, Felipe Contreras <felipe.contreras@×××××.com> wrote:
> Hi gentooists,
>
>  I've been reading news sites about some changes happening in Gentoo
>  and I thought it might be a good time to submit some ideas I've been
>  baking for several years.
>
>  I come from a Linux From Scratch background, I like the feeling of
>  knowing every single corner of my system and the fact that there isn't
>  anything that I don't want or need. However, typing every single
>  command by hand is far from ideal, so at first I started writing some
>  scripts and eventually I wrote a build system that suited my needs. I
>  did it in bash for several reasons.
>
>  After a while I realized bash wasn't exactly the best language to
>  write such thing. Mainly because:
>
>  a) The code ends up with a lot of stuff for handling strings properly
>  (like escaping sequences)

Yes this is annoying

>  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.

>  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?

>  d) Package information is difficult to fetch/store (no objects/struct)

Yes.

>
>  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?

>
>  Take this example:
>
>  package Binutils < Gnu
>   definition
>     @version = "2.17"
>     @name = "binutils"
>     super() # run the Gnu definition stuff
>
>     @config_opts = "--disable-nls --with-sysroot=\"#{$sys_root}\"
>  --enable-shared --disable-multilib"
>   end
>
>   steps
>     build
>       cd #{$top_build_dir}
>       mkdir -p #{@build_dir}
>       cd #{@build_dir}
>       :configure "script" => "../#{@dir}/configure", "opts" => @config_opts
>       make configure-host
>       make
>     end
>
>     install
>       cd #{$top_build_dir}
>       cd #{@build_dir}
>       make install
>     end
>   end
>  end
>
>  This is based on an already working prototype made in Ruby, so it's
>  biased towards Ruby facilities.

It looks Rakish ;)

>
>  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.

>
>  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 ;)

>
>  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.

>
>  I would like to hear your opinions on this matter.
>
>  --
>  Felipe Contreras
>
> --
>  gentoo-dev@l.g.o mailing list
>
>
-- 
gentoo-dev@l.g.o mailing list