On Thu, 31 Jul 2003 18:18:54 -0500
Nate Hill <vugdeox@freeshell.org> wrote:

> > The OpenBSD "FLAVOR" like solution would be for the name of the
> > package to change too (i.e. add "-gtk" to the filename and maybe
> > also package name).
> 
> Yes, I also realized that this problem exits as we speak. Basically, 
> binary packages reflect the settings in defaults.mk. Of course, doing 
> something as big as isolating GTK1-v-GTK2 support will make this 
> problem obvious (NetBSD will have to decide which to use by default). 
> I think the FLAVOR solution sounds good...

Now suppose you have a package with the following conditionals (just
three!): arts, esound, gtk.  And you can do any combination of the three
when building a package.  So, if you want to keep users of binary packages
happy, you could end up with:

foobar-arts, foobar-esound, foobar-gtk, foobar-arts-esound, foobar-arts-gtk,
foobar-esound-gtk, foobar-arts-esound-gtk... *sigh*

This seems quite flexible, but I doubt it is really good.  And imagine what
could happen with... mplayer hehe.

Generalizing many variables will cause packages to slowly introduce this
"feature" and will extend the problem.  Keeping variables package specific
avoid this problem somewhat.  IMHO.

And, just curious.  What could happen if you have USE_GTK=NO and you try to
build, say xmms?  You get "pkg useless without gtk" or the package is built
unconditionally as it's its default?

Cheers

-- 
Julio M. Merino Vidal <jmmv@menta.net>
The NetBSD Project - http://www.NetBSD.org/