Syntax, shall we?

reb0rn jyork at
Thu Jan 24 14:46:38 PST 2002

On Thu, 24 Jan 2002 13:15:02 -0500, 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.
> 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.

        What about trying something a bit broader.

        This tag would give a profiler a ton more options of what he can do with
his script, although i know this is definitely bordering on the smart
profile category, although i'd take this to be more dynamic than smart. 

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

        I think this is a very good idea, it allows for a lot of expansion.
Especially if ALFS is to ever turn into a valid PMS, which i know hasn't
been totally decided. Pretty much valid information could be put in here
such as dependencies, filenames, locations etc...

 >             <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.
> 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>).
> 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?
> 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>
> 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 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.
> Neven

Some other miscelaneous thoughts.

a log tag for <make> or more importantly make_install. Jesse i know we
spoke of this and you thought this should be done by the implementation.
But i think it might be worthwhile to build it into the syntax, and I'd
like to here what everyone else thinks about it.

search_replace bugs me ... my suggestion would be


or maybe even <switch>

Also i think textdump could use a rehash, here would be my suggestion

<mode>append</mode> also (overwrite,insert #) where #is line number
<dump>actual stuff to be dumped</dump>

One more :), this isn't my idea but it was brought up by someone else and
i liked it.


for multilined commands. Also i think this would make the profiles a bit
easier to read, at least for those who seem to be anti XML

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