Syntax, shall we?
jyork at lmasys.com
Thu Jan 24 19:04:29 PST 2002
On Thu, 24 Jan 2002 20:17:36 -0500, Felipe Contreras wrote:
> 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:
> <what>-f &glibc-version;</what>
> 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.
I would agree, of course if we agree on the <script> tag then I'll
shutup about all of this. My solution to this has been to dump stuff into a file
and then execute the file ... to do stuff like checking for existing
files etc ... and if you want to talk about ugly profiles ...
I think this comes down to do we want to leave options like this up to
the front-end developers, or create syntax so that the profilers have
these options. Leaving this up to the developers is sort of a bottleneck
as of right now it's pretty much up to whether or not Jesse and Neven
have time to put that into their respective front-ends assuming they
approve of the idea.
Putting the logical tags in, or something such as the script tag, makes
an very open playing field, where potentially everyone should be happy.
Of course i don't know how hard this would be to implement on the
developers side. I also think that opening up the syntax might well keep
more people interested in ALFS. If we create a syntax broad enough so that
it is capable of really doing what everyone wants it too, we probably
wouldn't have so many people working on their own projects.
> If you plan to give that power to xml profiles they will get insanely
> complex. I say let the code do that. Again:
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