Lots of ideas
haski at sezampro.yu
Wed Dec 26 08:21:11 PST 2001
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
> <package> <commands>
> <name>... <name>...
> <prebuild>... Like *build
> <build>... </commands>
Creating directories in /usr.
<dir>bin etc include lib sbin share src var</dir>
It could be useful perhaps, but it also could be "too much".
> 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.
> 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
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.
> 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.
> PS. Anyone interested in the current code of the parser please let me
Still at http://sourcer.sourceforge.net, I assume?
0.2.2 was the last one I checked.
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