Another try ( was Re: the forest through the trees )

atark at thepipeline.net atark at thepipeline.net
Thu Jun 28 17:57:49 PDT 2001


On Thursday 28 June 2001 01:27 am, you wrote:
> 1: *backend* portabality between programming languages.
>    ( I hope we can all agree that this certainly is not our aim )

I am under the impression that it did not matter what the backend was written 
in.  It could be written in anything from Shell to RPM to C.  There 
definately could be multiple backends.

> 2: *platform* portability between the backend and the xml spec
>    ( which can be remedied with a flexible command element )

If you mean hardware platform, then that should come automatically.  Wherever 
a backend will run, ALFS will (in theory) work.

> BUT, there's a third that I simply wasn't getting through my head,
> that I think others have been talking about but not clearly stating:
>
> 3: *profile* portability between systems!

I'm not sure I get this.

> > Coming back to the statement made above and in my other email: you don't
> > know for a fact that -R is available on the 'cp' you are assuming that
> > somebody has. Parameters to cp and other basic utils may not change much
> > or are the same on every system, but when it comes to other programs you
> > don't want to rely on that. Perhaps you really need to use a non-gcc
> > compiler that works pretty much the same but has a less parameters (say
> > -malign_double doesn't exist, you could get an error when passing that,
> > unless you describe it as something. Then you can decide whether you use
> > it (by assigning a value to the description) or leave it blank if it's
> > not supported on your choice of cc).
>
>   Exactly why I've been lobying for my 'command' tag markup idea:
>
> <command name='mv' src='/bin'>
>   <opt name='-f' value=''>
>   <opt name='' value='/foo'>
>   <opt name='' value='/bar'>
> </command>

I'm not sure you are getting it.  That's exacly why we don't want to use a 
command tag for everything.  Now yes, in some special cases the command tag 
is good, like the Windowmaker example.  But in general for the typical copy, 
move, link and even to an extent make and configure, these should be 
abstracted as much as possible.

Now that not to say a profile writer could use the command tag for 
everything, they surley could but I don't think that is the optimal way to 
write a profile.  I sure don't want to be forced to do that.

>   You cannot, 1 - have the XML heavily abstract your data and,
>   2 - write the code to make guesses, assumptions and an indefinite
>   amount of workarounds - *either one* of those items are poor practice,
>   and I'm seeing people want to utilize *both*?  You'll end up
>   developing/designing your way right into a dead end, with nothing
>   but an ugly mess to show for it.

as to #1 sure you can and as to #2 you don't have to write code that only 
guesses.  Some amount smart guess work is good, but there should be a solid 
way around it.

For example:

<package name=bash ver=2.05>
	<unpack />
</package>

The unpack function called by the parser should be able to guess that the 
archive is likely to be $name-$ver.tar.bz2.  And likewise it could be written 
to handle any for of compression, not just bzip2.  Of course if you have a 
nonstandard archive you could opt to define it manually.  

<unpack>bash-2.05-patched.tar.bz2</unpack>

This gives the profile write BOTH simplicity and control.

>   ( I *really* don't think we should focus on portability at the
>   *backend* -- we should decide what language we want to write it
>   in, and that's that.  If somebody decides for some freaky reason
>   to rewrite the backend in some other language - that's *their*
>   effort, not ours. I think perl or python fit perfectly with our
>   requirements. As far as portability on the *platform* end - that's
>   instantly and elegantly acheivable through allowing the *users*
>   to specify the platform dependant tools and commands used in the
>   xml profile, as I've displayed with the 'command' element. )

My main point to make here is that anybody should be able to take any profile 
and write a backend  in any language and the results would be the same.   In 
other words take the "official" ALFS profile.  You should ultimatly be able 
to take a backend written in Perl, C, java whatever and run it on any system 
that it will run on (i386, sparc etc.) and get the same result.  This is my 
impression of ALFS.  You should be allowing the profile writers freedom to 
write the profile and not have to think about how the backend will install it.

>   And so yeah - versatile and modular is killer; and it's going
>   to require some serious flexibility and design -- ultimately
>   that means we're going to need to be prepared for some complexity
>   here guys.

What I am talking about is even more versitile and modular that what you are 
talking about.  The profile writes should be able to have as much power and 
control as possible.  But it should also be as simple as possible.  The less 
that is in a profile (the more abstract), the easier it is to maintain.  

And once again the backend whatever language it is written in shold be doing 
most of the work, WITHOUT taking away control from the profile writer.

--Andy 
atark at thepipeline.net
-- 
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the alfs-discuss mailing list