Dependencies, their tracking and what we need to improve.

[Dennis Veatch]

On Thursday, July 14, 2011 11:50:19 PM Auke Kok wrote:
> On 07/14/2011 07:20 AM, Jean-Michel Bruenn wrote:
> > Hey
> > 
> >> if we had a way to build packages in a completely pristine environment
> >> without non-preferred dependencies, then this would not be a problem.
> >> 
> >> the cost of building in a chroot with only dependencies are that it is
> >> slow. and you might as well run an rpm-based system almost, since in
> >> order to obtain the flexibility that lunar grants, we'd have to do a
> >> LOT
> >> more dependency and option mapping than we do now.
> >> 
> >> Solving that problem... wouldn't be worth doing in the current
> >> codebase.
> > 
> > The interesting question behind all this is: Do we want an improvement
> > or not? Is it worth, trying to improve this or not? If it's not worth
> > or possible with the current codebase, what steps could we do to
> > make it worth it/possible. Do we have any alternatives? Apart from
> > switching to rpm's of course :)
> 
> we could even switch to rpm... I'm not kidding.
> 
> the problem isn't the packaging format. the problem is the level of
> freedom that you want. no current build system will give it to you, so,
> switching package formats doesn't fill the gap.
> 
> > Also, "if we had a way .. in a completly pristine environment" Let's
> > assume, we do it like this. I wrote a howto for a Chrooted Lunar,
> > which is working quite nice. I've been using that thing first as zone in
> > opensolaris, later as 32bit chroot for lunar and now just for testing.
> > I might be able to make it a lot smaller (~500 MB packed, 1.8 G
> > unpacked) for the above purpose, and i might make it install
> > automatically using "lchroot" or something. So let's assume further, we
> > take this chroot, for the purpose of doing dependency tracking, even if
> > that sounds a bit.. masochistic. What possible improvements could we
> > do, to make it "faster" (as you said it would be slow) and what
> > alternatives do we have?
> 
> stop coding it in bash, start over in C.

I wouldn't be opposed to C or perl, python or whatever. 

What I do not see any of those being able to solve is the root of the problem 
or nearly so; the lack of an on/off switch. As I mentioned, there are many 
instances of configure and cmake that will look for an application but give you 
no way to enable/disable. How would you address that with C?

> 

-- 
Dennis `stumbles` Veatch
Lunar Linux Developer
http://www.lunar-linux.org/