Syntax, shall we?
al593181 at mail.mty.itesm.mx
Thu Jan 24 15:56:17 PST 2002
On Thu, Jan 24, 2002 at 05:46:38PM -0500, reb0rn wrote:
> On Thu, 24 Jan 2002 13:15:02 -0500, Neven Has wrote:
> > 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">
> > http://automated.linuxfromscratch.org/LFS-3.1/bash.xml
> > </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.
In my personal opinion not everything should be on the profile. I think
a profile should only store data about a package.
> > 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...
This is a cache file that comes from sourcer, all this iformation is
autogenerated and covers everything that I have ever used.
NEED="bash binutils diffutils fileutils gcc grep gzip make mawk sed sh-utils textutils"
This file needs a version, so there is another file called glibc.ver that
has "2.2.5" in this case, and if glibc-2.2.6 the cache doesn't need to
be modified, only the glibc.ver file.
Now that I have explained somewhat how it works, I think that from this
basic information an xml alfs file can be generated.
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