Lots of ideas

Felipe Contreras al593181 at mail.mty.itesm.mx
Wed Dec 26 21:58:16 PST 2001


On Wed, Dec 26, 2001 at 05:21:11PM +0100, Neven Has wrote:
> On Sun, Dec 16, 2001 at 10:09:23PM -0600, Felipe Contreras wrote:
> > 1. There should not be commands alone.
> > 
> > IMHO each command should have an identification, be inside a package
> > like vim, or inside something like "creatingdirs", that way, no commands
> > are floating scatered. The advantage come when you want to resume the
> > installation, or select special steps on it, it's much easier this way
> > to indentify those commands that are not under any container. Something
> > like:
> > 
> > <package>			<commands>
> > 	<name>...			<name>...
> > 	<prebuild>...			Like *build
> > 	<build>...		</commands>
> > 	<postbuild>...
> > </package>
> 
> Or:
> 
> <group>
>     <description>
>         Creating directories in /usr.
>     </description>
> 
>     <commands>
>         <mkdir>
>             <base>&LFS;</base>
>             <dir>usr</dir>
>         </mkdir>
> 
>         <mkdir>
>             <base>&LFS;/usr</base>
>             <dir>bin etc include lib sbin share src var</dir>
>         </mkdir>
>     </commands>
> </group>
> 
> It could be useful perhaps, but it also could be "too much".

I like this idea, might be using groups will be at the end the best
option, but what should be grouped? commands? Anyway you missed the
"name" tag there, so the group can be identified.

The description is also a good idea that could be used in the future.

> > 3. The information should be divided
> > 
> > I think eack package have a lot of information that will be better
> > handled if it were divided. For example, I think that the "setup
> > information" have nothing to do with the current tarballs and patches,
> > tarballs change, but the "setup information" might not. The tools that
> > read this information can easily generate instructions to unpack the
> > tarballs and patches. Also there is the "misc information" like the
> > licence, author, download location, etc.  and it will not fit in the
> > current alfs format. Finally there is the "build information" that says
> > what package to setup one by one, when to chrooted, etc.
> > 
> > I know this is a great change and I think it will not be well accepted,
> > but anyway that's what I think that should be done.
> 
> As I said in some other mail, I think it would be nice to separate package
> information from its building instructions.

Good, might be with another backend? I don't know, it might be better
since the information will not be commands.

> > 4. C Front end-Back end no no
> > 
> > As I stated in a mail ago, "a bad thing about alfs in c", there might be
> > problems with the "execute" tags. There might a lot of discussion but
> > the point is simple, there is no natural way to interact with bash in c.
> > Believe me, I tryied to move my project from bash to c, and I never
> > figured out a nice way to check what bash was doing. I tryed pipes,
> > checked out sockets, and a lot of things, and at last I know that it can
> > be done, but really I didn't want that level of complexity for something
> > so simple. So if you ask me, c should be banned for executing shell
> > commands.
> 
> But I don't think that we should even talk about some specific language
> and ALFS. This assuming (and hoping) we're still for the "language
> independence" of both backend and frontend.
> 
> I do agree that executing shell commands in C is not that easy (but it's
> possible). But that should only concern implementation writers.
> 
> In general, discussing about disadvantages of some language for ALFS
> inevitably leads to discussion about what language is best suited for it.

I agree, there should language independence, just trying to say what I
think.

> > 5. The solution
> > 
> > The solution from my point of view, is to write an alfsparser as I'm
> > doing right now. This parser should receive as input what package, step,
> > and number of command to parse and it will return the parsed sh
> > command ready to be executed.
> 
> This is a good solution with some advantages, but I see it only as one of
> the implementations. I don't think that we should force all implementation
> writers to start using the same protocol for parsing the profiles.
> I think there is (and should be) enough room for different approaches.
> 
> That doesn't mean that I won't decide tomorrow that I could be better using
> your "alfsparse" for nALFS and start doing that. But again, that would be
> decision of just one of the implementation writers.

Ok, I can resume all of my ideas into one, to make my parser functional,
and not doing nasty stuff. The should be some grouping, commands into
steps, steps into packages or groups or whatever you want to call them,
and those to xml files, or all of them in a single file, whatever you
want.

xml file->pkg or group->step->command number

This way each command in the file can be accessed easily.

> > PS. Anyone interested in the current code of the parser please let me
> > know.
> 
> Still at http://sourcer.sourceforge.net, I assume?
> 0.2.2 was the last one I checked.

Not really, that's a "parser" for the format of sourcer, but I have been
working on an ALFS parser. Currently all exept one "tag" are parsed, but
it's not functional since it just outputs all the commands parsed. If
some kind of "grouping" is used in the official ALFS format the I can
make it usefull.

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