Syntax, shall we?

Felipe Contreras al593181 at mail.mty.itesm.mx
Thu Jan 24 17:18:05 PST 2002


On Thu, Jan 24, 2002 at 07:44:36PM -0500, reb0rn wrote:
> >> >         <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.
> 
>   I would disagree with that, for the following reasons. While the
> profiles must contain data about the package. These profiles are also
> instructions on how to install the program. If you are not going to
> include this sort of information in the profile, how would you suggest
> getting that sort of information to the front-end program. It doesn't
> seem very plausible to have the front-end collect that sort of
> information on it's own, with nothing extra in the profile. I suppose
>  you could totally skip it all together, but then you would be
> restricting the overall functionality.

Yes, that's true, but that's only true on the setup instructions part.
Untar, patch, clean, I don't consider them as setup intructions simply
because you don't need to now them, you can guess them and the code
should too.

Also, altought you can say that all the instructions necesary to build a
package should be in the profile. Following this approach you could do:

<if>
	<what>-f &glibc-version;</what>
	<do>
		<wget>ftp://ftp.gnu.org/pub/gnu/glibc/&glibc-version;</wget>
	</do>
</if>

The point I want to emphysize is that xml was made to store information,
not run commands. So, why don't sore information? Setup instructions are
information, it's plain text commands, just as the lfs book, and that's
all you need in order to know how to build a package. But sure those
shell commands are in a "neat" format so they can be extendable.

If you plan to give that power to xml profiles they will get insanely
complex. I say let the code do that. Again:

...
<sources>
	<source>
		<uri>file://$packages_dir/base/mawk1.3.3.tar.bz2</uri>
		<uri>ftp://ftp.whidbey.net/pub/brennan/mawk-1.3.3.tar.gz</uri>
		<uri>ftp://ftp.linuxfromscratch.org/lfs-packages/cvs/mawk-1.3.3.tar.bz2</uri>
	</source>
	<source>
		<uri>file://$packages_dir/base/mawk1.3.3.patch.bz2</uri>
	</source>
</sources>
...

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