Syntax, shall we?

Felipe Contreras 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.
> 
>         <evaluate>
>                 <check></check>
>                 <iftrue></iftrue>
>                 <iffalse></iffalse
>         </evaluate>
>                 
>         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.

NAME="glibc"
GROUP="base"
PRFX="/usr"
MAINTAR_LIST="glibc-${VERSION}.tar"
PATCH_LIST=""
EXTRATAR_LIST="glibc-linuxthreads-${VERSION}.tar"
FILE_LIST=""
ROOT_DIR="glibc-${VERSION}"
NO_RUN=""
DIR="ftp://ftp.gnu.org/pub/glibc"
DFILE="glibc-${VERSION}.tar.gz"
RFILE="ftp://ftp.gnu.org/pub/glibc/glibc-${VERSION}.tar.gz"
AFILE="ftp://ftp.linuxfromscratch.org/lfs-packages/cvs/glibc-${VERSION}.tar.bz2"
OFILE=""
TAR_EXTRA_DIR="$ROOT_DIR"
PATCH_DIR="$ROOT_DIR"
PATCH_EXTRA_OPTS=""
CLEANS="glibc-*/"
TYPE=""
PATCH_LEVEL="1"
CFLAGS=""
CXXFLAGS="$CFLAGS"
UNTAR_DIR="\$build_dir"
NEED="bash binutils diffutils fileutils gcc grep gzip make mawk sed sh-utils textutils"
LIKES=""

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.

-- 
Felipe Contreras
-- 
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 mailing list