Re: Re: ebuilds in XML

"Andrew Aylett" <[email protected]> wrote:

> "Kevin Horn" <[email protected]> writes:
>
> > very spiffy!  Obviously just a prototype, but it demonstrates your
> > idea very nicely.  Using a system like this, one could store the
> > metadata portion of an ebuild as XML, have the actual install script
> > auto-generated, and thereby avoid having to rewrite a lot of common
> > tasks in bash (or whatever shell language).  The XSLT could rapidly
> > become non-trivial, but I think this is a great direction to
> > explore.
> >
> > Hmmm...could a particular package have one XML file, and a number of
> > different XSLT templates for different platforms?  i.e. one XML file
> > per package, and one XSLT file per platform, all packages use the
> > same XSLT transform for a particular platform?
> >
> > Hmmm, also, perhaps one might need several "layers" of XSLT
> > transform...  XML + XSLT1 -> XML2 XML2 + XSLT -> Bash? install
> > script I'm not even sure why you would do this, but it could come in
> > handy?  maybe?
>
> Not so much devil's advocate, but I will say that this sounds somewhat
> nightmarish to write to me.

Probably...

>
> XML may be good for a lot of things, but it isn't a panacea -- it's
> designed to mark up content, not to present a list of actions (which
> is exactly what bash was desined for).  Using bash functions
> alleviates the need to re-write common tasks.
>

Please continue to remind me of this.  I tend to have an (unhealthy?)
fascination with XML+XSLT.  Sometimes I forget how difficult things get with
XSLT, and get caught up in the "coolness" (IMO) of it.

[snip]

> I tend towards the thought that while XML is very good for portability
> of data, I don't ever want to have to write any by hand again.

Perfectly reasonable.  It gets quite messy, unless the dialect is VERY
simple.

> Personally, I would want to implement common operations in $LANGUAGE,
> devise some standard style of puttings things together in a file
> (probably using ReStructured Text for documentation) then let the
> automated tools take over.  Something like PyDoc would be be good for
> reading about packages &c., we can also build utils to grab the
> documentation out of the package, to make sure that packages have
> everything in the right place when checked-in.
>
> I think I quite like Gentoo's current ebuld syntax, actually.  It's
> nice and easy to understand what's going on, at least on the surface.
> Of course, underneath it could all be very different (and a Zynot
> implementation of portage probably would be very different) but on the
> surface it could still look very nearly the same.
>

I like it too.  I just get irritated at some of it's limitations.
Occaisionally I'll run into an ebuild that I can't read because that
package's build process depends on a config file or some such that the
Gentoo packager has tweaked using SED/AWK/other.

sed and awk make my head hurt.  There's got to be a better way...

Of course, putting stuff in XML doesn't fix any of this, but it's COOL (at
least in theory).  Maybe it's like the old saying about Communism:

"Communism works in THEORY."

Anyways, thanks for your help in getting my head out of the clouds.  No
matter which way this is implemented, there will be non-trivial challenges.
I guess the question is: "Does solution X (in this case XML) solve more
problems than it creates?"

Later,
Kevin Horn