Dependencies, their tracking and what we need to improve.

[wookietreiber]

On Fri, Jul 15, 2011 at 06:45:21AM -0400, Dennis Veatch wrote:
> 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?

doesn't depend on the language

what I think could solve the problem is to combine CONFIGURE and DEPENDS or at
least use logic in any way in depends -- both solve hell'a more problems, e.g.

with-x? then
	with-x-screensaver?
else
	with-direct-fb?
...

currently this kind of configuration is impossible to do right ...

regards
wookietreiber