Planning an overall direction for LFS

Rich Edelman rcedelman at
Fri Feb 29 10:46:26 PST 2008

On Friday 29 February 2008 11:44, Bryan Kadzban wrote:
> On Fri, Feb 29, 2008 at 11:22:24AM -0600, Rich Edelman wrote:
> > While not all package managers keep configure and build as separate steps
> > (in fact, I'm not aware of any that actually do have them as separate
> > steps),
> The package-user method's current scripts do.  However, I'm not sure if
> that really counts, or if the fact that the current scripts treat them
> separately means they always have to be kept separate.  The configure
> function is what I use to apply patches and seds and other stuff, too,
> but that could also be moved into the "build" step.

I believe in the RPM scheme, patching and seds are taken care of in the 'prep' 
stage, after extacting the sources. configure is typically part of the build 
process there. I'm curious how to reflect this and the other pre and post 
install steps, do we really want to have <pre-install> and <post-install> 
types of tags? I guess in the original sense of having generic xml spec 
files, that's what would be done, though.

> > I think the editors should be concerned only with making sure the
> > commands work in jhalfs or in a copy & paste mode.
> As long as they're split up sanely, I think that would work.  There's
> only one way to *really* test it, though, and that's to run through it
> with some sort of PM system.  Maybe a dummy system would be enough to
> verify that the right things are happening at the right times, but I'm
> not really sure how you'd test that either.

I really don't think the various editors (some of whom use no package 
management at all) need to be concerned with each different PM that's in use,
or any PM at all, which is why I suggested volunteers that test each 
PM-specific case. The editors just need to make sure patches and the overall 
instructions are up to date and correct. That'll take care of 90% of the 
problem right there. Those of us that want integrated PM options or whatever 
need to step up to the plate and do some work, too. 

More information about the lfs-dev mailing list