ALFS Status: Past and future [was Re: new guy, newbie questions.]
mark.uzumati at virgin.net
Mon Jan 21 13:55:15 PST 2002
On 2002.01.21 02:42 Felipe Contreras wrote:
> On Sun, Jan 20, 2002 at 08:33:54PM +0000, Mark Ellis wrote:
> > On 2002.01.20 02:58 Felipe Contreras wrote:
> > >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
> > >"mcrypt" might install mcrypt with the defaults for every package.
> > >no
> > >more information is provided why not to guess it? We are talking
> > >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
> > example would be that while most (all ?) GNU software uses
> > perl uses "Configure", and you don't configure lilo at all, this has
> > be hardcoded somewhere.
> Yes that's true, that what I call setup information, 50% of the time
> 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
> 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
> guess everything that might be necesary, save it, and then, generate
> ALFS xml profile. Whould you like it?
I think i follow you. So for instance if there is no explicit <unpack>,
you'd look in the standard package dir for an archive file matching the
package name and version and unpack it into the standard build dir ?
Then if there was no explicit <configure> you'd just run configure.
Good idea, perhaps tricky but good, its a shame there are so many
naming and versioning schemes around. Certainly i've been thinking
about using standard directories for archives, i think this came up in
the discussion about auto downloads.
> > >There can even be different levels of processing an the
> > >information can be stored somewhere. This requieres a little bit
> > >explanation but the point is that it's different to add a patch
> > >update the version.
> > >
> > >Also I don't like C for bash stuff, I even tryied Python but I had
> > >luck. It seems bash was not done to interact with it, but that
> > >mean it can't be done.
> > >
> > Personally i'd rather not interact with bash at all, it's not
> > 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.
Environment vars are easy in perl, i presume its similar in C, though
i've never tried. File handling the same, use the perl calls or C
library/system calls. This was why i preferred the <options> element
over passing arbitrary params to copy et al., 'cos i didn't want to use
sed can be exec'ed without invoking the shell, you just have to be
careful not to allow shell tricks or do some globbing yourself. It's
trickier and some may argue your reinventing the wheel of course :)
Alternatively, use internal regexps. You'll always want to have the
ability to perform some stuff through the shell, but it is possible to
avoid it in a lot of cases.
> > >Most of the work I've done has been to make a good and smart design
> > >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
> > >a
> > >script with vars like BASH-VERSION=2.05.
> > >
I agree that a lot of unnecessary repetition occurs in the current
profiles, hopefully now that we have a reasonably good build system
these can move up the list.
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