Syntax, shall we?
al593181 at mail.mty.itesm.mx
Thu Jan 24 20:54:06 PST 2002
On Thu, Jan 24, 2002 at 10:04:29PM -0500, reb0rn wrote:
> On Thu, 24 Jan 2002 20:17:36 -0500, Felipe Contreras wrote:
> >> 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.
> 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.
Ok, we can make some commands optional and let the developers decide
wheater to run them or not. Something like:
<step name="clean" importance="optional">
But I'll always disagree on the "source preparation" part, because we
are typing commands, and we are not letting different source retrieval
methods. The best should be to define some places to get each one of the
files, and let the code try to get it, then the preparation step can
decide what to untar, patch, etc.
> 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.
It depends on how each person want to implement it, but as for how
everyone here want to do it there should not be any problem, in fact
it's very easy.
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