Syntax, shall we?

Mark Ellis mark.uzumati at
Fri Jan 25 02:09:15 PST 2002

On 2002.01.24 18:15 Neven Has wrote:
> On Thu, Jan 24, 2002 at 03:59:54AM -0800, Jesse Tie-Ten-Quee wrote:
> > Allright, let's get this big ball of wax started.
> >
> > First, I want to express that all suggestions are welcome and will
> be
> > considered and discussed, at least as much as we can.
> >
> > I was going to start off by posting a few new ideas i had with the
> > syntax, but i want to hear from a few people first that have
> mentioned
> > they have a few ace's up there sleeves. (*waves at Neven*)
> *waves back* :)
> I was waiting for your ideas, since these below are more or less old
> and already discussed. But still, a new point of view is also
> desperately
> needed for these - there might be a lot of flows in there.
> First, these are all "relative" to the syntax used by both Perl ALFS
> and nALFS, which is a small (at least it was at the beginning)
> modification
> of the one from ADG.
> Unfortunately there isn't a document describing this current syntax,
> so
> the best thing one can do is check out the profiles written using it.
> Which raises the question - what should we use to refer to current
> syntax
> we are now working on?
> ADG-like document is great when syntax is complete, for the profile
> writer (or developer) to start writing profiles (or implementations)
> but,
> IMHO, it's not that practical for discussing and improving the syntax
> at this stage.
> I think DTD could serve us well for this, it's not that hard to
> understand,
> even for someone who doesn't know it that well (like me for example
> :).
> Mark has one at:
> Not everything is represented with it (for example the values of
> <options>
> for different elements), but we could add some comments to it and make
> it really useful for this.
> I could send it here (or better first to Mark, to correct my mistakes
> :),
> modified like that, to show what I mean.
> Second, not all of the below are mine ideas. Some are from my various
> TODO and TODISCUSS :) lists, and with some of them I might not even
> agree
> that much.
> They are just thrown here, in no particular order:
> o   The question Mark raised is whether we should force the order for
>     certain elements or not. For example, in:
>         <configure>
>             <base>&build_dir;/&automake-directory;</base>
>             <param>--prefix=/usr</param>
>         </configure>
>     does <base> _have_ to go first, before <param> or not.
>     If we start using DTD for validating profiles, it seems (I'm not
>     the expert) that some ordering will have to be forced?
>     Personally I'm not for that kind of forcing. We could just add a
> note
>     (to the official syntax document in the future) that if you want
> to
>     validate your profiles with DTD you'll have to be careful with the
>     order of elements. Or something like that.

Been looking more at XML Schema recently, and we definitely wont have 
this problem using it. Downsides are it is a pig to read, it doesn't 
seem that widely used yet, and i haven't had time to fully explore it 
yet :(

> o   Should we have that <include> in the syntax? This element seemed
> like
>     a great thing at first, but now I'm not that sure.
>     As someone already mentioned, it could cause some problems in the
>     future, if we start using some third party XML software. For
> example,
>     XML editor won't include another profile when it encounters
> <include>,
>     it will just leave it be. It could be said that this element
> "breaks
>     the XML" in a way. (Don't take this literally. :)
>     For what it's used now, something like XInclude can easily replace
> it.
>     But, on the other hand, we won't be able to expend it to suit our
>     needs if we start using XInclude instead. There is so much stuff
> that
>     could be added to our own <include> that would allow
> implementations to
>     do a lot of nice things. For example, by specifying remote url
> like:
>         <location type="remote">
>         </location>
>     implementation could either launch some program to grab that
> profile,
>     checking if it's successfully transferred, and acting accordingly.
> Or,
>     have it's own code for grabbing the profile with some nice status
>     reporting or other similar perversions.

I think the only thing we might gain from our own include is somethng 
like status reporting, XInclude will support remote fetching etc. At 
the moment i could take it or leave it.

> o   What I think is a very good idea is something like:
>         <package>
>             <package_info> <!-- name is just an example -->
>                 <name></name>
>                 <version></version>
>             </package_info>
>             <package_building_instructions> <!-- name is just an
> example -->
>                 <prebuild></prebuild>
>                 <build></build>
>                 <postbuild></postbuild>
>             </package_building_instructions>
>         </package>
>     As I said on this list, it always bothered me a bit that info like
> name
>     and version of the package are on the same level as prebuild,
> build
>     and postbuild information. All together inside <package>.
>     I think profile would be much more readable if we split that
>     information.
>     Then, latter, we could also add things like <location>,
> <homepage>,
>     <description>, <author> - all in <package_info> - without
> "polluting"
>     the <package> itself.
>     Note that this change would break the profiles (at least with
> current
>     implementations), but I think it's worth it.

I like this, it would also allow a section that is maybe more flexible 
in implementation, with more "optional" syntax features maybe put in 
package info, while the build section is quite strict.

> o   New element - <group>, or similar - was suggested here. Inside it,
> all
>     the regular elements are to be found. For example it could look
> like:
>         <group>
>             <name>dirs_in_usr</name>
>             <description>Creating directories in /usr</description>
>             <instructions>
>                 <mkdir></mkdir>
>                 ...
>             </instructions>
>         </group>
>     Personally, I don't thing this is necessary. I do agree that it
> might
>     improve the look of the profiles and make them more readable
> perhaps,
>     but if people decide that something like this should be included
> in
>     the syntax, I don't thing it should become mandatory (all elements
> in
>     some <group> or <package>).

Agree completely.

> o   Thanks to Fabien Steinmetz, there is:
>         <setenv mode="append">
>             <variable>PATH</variable>
>             <value>:/static/bin</value> <!-- Sounds familiar? ;) -->
>         </setenv>
>     now, implemented in nALFS.
>     I think this can be very useful (think about PATH above) and
> perhaps
>     added to the syntax?

Ooh, I like this !

> o   One general thing - where ever possible, I think we should allow
>     multiple content in elements, separated with whitespace. For
> example:
>         <unpack>
>             <archive>
>                 &LFS;&packages_dir;/&binutils-package;
> /alternative/location/if/first/one/fails/&binutils-package;
>             </archive>
>             <destination>&LFS;&build_dir;</destination>
>         </unpack>

Again, agree completely.

> o   Should we rename <base>? I never liked that name much, but I still
>     didn't want to use <dir> - this is the working directory for the
> most
>     elements and I think it should be as descriptive name as possible.
>     But as someone said, we kind of got used to it. :)

I'd forgotten that thread completely :) About the only thing i can come 
up with now that might be an improvement is <base_dir>

> I might add a few more ideas latter, when I remember them. :)
> All in all, I think that the current syntax is pretty close to
> something
> we could all agree to use.

Agreed, some things would be nice to add but as a base i think it's 
pretty good.

Off on holiday now, have fun, please don't generate _too_ much for me 
to read when i get back :)

Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list