enabling/disabling features (Was Re: RE Questions with Auke Kok)

[Jasper Huijsmans]

On Wed, 02 Jul 2003 13:46:22 +0200
Couannette <couannette at free.fr> wrote:
...
> jasper at lunar-linux.org wrote :
> 
> If you say yes to an optional depends you'd want to use it, right? If
> you don't want to use it, you say no ... Lin doesn't uninstall modules
> if you say no to an optional depends.
> 
> Yes, but : configure script will detect software installed watever
> "optional_depends" answer you make....
> There are two different things.
> 

Well, lunar can't do anything about packages not allowing --disable-foo,
but for all other cases, the optional depends question should also be
asked when the module is already installed; I thought it was.

> Moritz Heiber wrote:
> 
> >I don't get you here. I'm using the original ALSA driver along with
> >the OSS emulation provided by that driver. Therefore I need to have
> >the ALSA packages installed and no kernel drivers.
> >
> >Moreover Jasper is right: If an app explitcitly requieres ALSA it
> >definitly needs it to compile.
> >
> >  
> >
> If you use ALSA driver with OSS emulation you don't need ALSA libs.
> Therefore, if I want to build apps with little library footprint I
> want do disable ALSA support in configuration stage. Not in lin deps.
> 

the optional_depends can set configure options ...

> The main reason for building apps with little (minimal) library binds
> is that UNIX/Linux systems tend to be more and more complex. And
> complexity leads to headaches when something goes wrong. A more
> complex system is more subject to failure than a simple one. Take a
> look at rescent major anoyment in Linux software :
> 
> - freetype / XFree / fontconfig / pango / ghostscript and friends ...
> - gdk / imlib / gtk / gnome libs (ui & all) and all gnome2 stuff ...
> - gettext / glibc ...
> 
> Beware : I don't want everything to be choosen in lin stage. It would
> be more difficult to use lunar. A common set of dependencies could be
> defined (at the moment : it's implemented in "depends and
> optional_depends" system), and a complete list of depends could be
> accessible to tune special module &/or tree of modules (hierarchy of
> modules that provides a system like gnome/kde/xfce/...).
> 

I don't get this. Do you want a "disable this module in the configure
stage of all relevant modules" option? 

If not can you give an example of how your idea would work.

> Example of incompatibilities :
> 
> transcode won't compile with latest libdv. And this one is needed by
> kino or dv apps. Thus I have to lrm libdv to build transcode. Upon
> lunar update all things get weird and broken ...
> 
> MPlayer won't compile with latest libdvdnav...

Ok, this is a separate problem. This is almost impossible to solve
except by removing and reinstalling conflicting modules in PRE_BUILD and
POST_INSTALL or something.

> 
> Well. How could we create this matrix ? Do each configure provides a
> clean interface for custom selection of dependencies ?
> 

Aah, is that what you want. Well, one database with all possible
interdependencies doesn't sound very feasible to me. I can't see at all
how this could be implemented.

	Jasper