Syntax, shall we?
jyork at lmasys.com
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:
> 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
> 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
> 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">
> 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_info> <!-- name is just an example -->
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
> 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
> 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,
> the regular elements are to be found. For example it could look
> <description>Creating directories in /usr</description>
> 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">
> <value>:/static/bin</value> <!-- Sounds familiar? ;) -->
> 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
> 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
> 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.
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 linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message
More information about the alfs-discuss