ALFS Status: Past and future [was Re: new guy, newbie questions.]

Felipe Contreras al593181 at mail.mty.itesm.mx
Sun Jan 20 18:42:31 PST 2002


On Sun, Jan 20, 2002 at 08:33:54PM +0000, Mark Ellis wrote:
> On 2002.01.20 02:58 Felipe Contreras wrote:
> >On Sat, Jan 19, 2002 at 02:42:20PM -0800, Jesse Tie-Ten-Quee wrote:
> >> So, I do not plan on ignoring anyone.  That, as you mentioned would
> >be a
> >> true waste.  But at the same time, i'm not going to spend 6 months,
> >> debating about the best way to go, the best implementation or the
> >best
> >> syntax.  I am sick and tired of it, i've been doing it for nearly
> >two
> >> years.. i hope that doesn't make me look like i have no patience.
> >I've
> >> actually gained quite alot latelly, but the fact is, it's better to
> >> start with something and build on it, then have nothing to show for
> >6
> >> months of work.  Because... in reality we have nothing to show for
> >the
> >> last 2 years, perhaps the only thing that we do have is the very old
> >> syntax we had prototyped. (which we never had plans to use for
> >longer
> >> then a few months.. which is still being used)
> >
> >As I have worked very hard for my own project since some time I think
> >my
> >opinion whould be good at least to hear it.
> >
> >I don't want to be pessimist, but I want to express my feeling that
> >the
> >current ideas is not the right way. I like the idea of xml profiles,
> >but
> >I think there should be more processing, lot's of things can be
> >guessed
> >by some code and generate the finall commands to run.
> >
> >There should be less hardcoded information so for example just having
> >"mcrypt" might install mcrypt with the defaults for every package. If
> >no
> >more information is provided why not to guess it? We are talking about
> >an "automated" system, why no to make it smart an think the most it
> >can
> >in order to help us?
> >
> 
> For certain things yes i agree, but you cant guess everything. A simple 
> example would be that while most (all ?) GNU software uses "configure", 
> perl uses "Configure", and you don't configure lilo at all, this has to 
> be hardcoded somewhere.

Yes that's true, that what I call setup information, 50% of the time is
configure, make all install, but the rest is special. So this commands
should be hardcoded. But the untar, patch, clean, etc. can be easily
guessed and usually the commands depend on the version, and that's the
part I consider more important at first. I really don't like to type all
the tars, and patch commands by hand, not even to write a profile.

Might be I should say what you want... Image a "smart" program that
looks for files on the directories you specify, some hardcoded
information and setup instructions that it alredy has, then be smart and
guess everything that might be necesary, save it, and then, generate an
ALFS xml profile. Whould you like it?
 
> >There can even be different levels of processing an the corresponding
> >information can be stored somewhere. This requieres a little bit more
> >explanation but the point is that it's different to add a patch than
> >update the version.
> >
> >Also I don't like C for bash stuff, I even tryied Python but I had no
> >luck. It seems bash was not done to interact with it, but that doesn't
> >mean it can't be done.
> >
> 
> Personally i'd rather not interact with bash at all, it's not strictly 
> necessary, just easier in some cases.

Migt be I'm just seeing the ovious, how do you plan to do for example:

1. Different CFLAGS and CPPFLAGS for each package.
2. Do simple cp, mv, ln, sed, work when you have to cd.

I have not explored this idea, but when these issues are solved I'll
think a little bit more on it. BTW. I don't like the base tag in the
alfs format as a solution for number 2.

> >Most of the work I've done has been to make a good and smart design so
> >I
> >don't have to type everything. That's why I don't like the current
> >xml format, you have to specify almost everything! It seems much more
> >a
> >script with vars like BASH-VERSION=2.05.
> >
> >I'll really like to work on ALFS, I even did a parser following an
> >approach that has alredy worked to me since a while, but no one except
> >Neven Has seems to care about my ideas. I'm sad you said "let's start
> 
> Sorry Felipe, heres another hand up for someone following your 
> comments, just quietly :)

Oh, well, I'm heard :)

-- 
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