Subject: Re: Consistent "Optional Dependecy" handling
To: None <>
From: Nate Hill <>
List: tech-pkg
Date: 07/31/2003 19:31:20
Damnit! I can't seem to send mail... Here it is:
On Thu July 31 2003 18:33, Juan RP wrote:
> On Thu, Jul 31, 2003 at 06:32:55PM -0500, Nate Hill wrote:
> > Okay, I see that there is already a USE_OSS flag (which is
> > undefined default) and it is checked in kdemultimedia3:
> >
> > .if defined(USE_OSS)
> > CONFIGURE_ARGS+=        --enable-audio=oss
> > .endif
> >
> > My question is wether I can implement this by just adding a
> > USE_GTK flag in Is there some kludge that
> > needs changing elsewhere?
> is only used to see what commons variables we
> can use. You will have to do on any package that uses GTK, btw I
> don't like this option, because we don't want many differents
> binaries packages, instead I prefer package-gtk or package-esd or
> whatever.

It has come to my attention that this binary package "issue" is going 
to become a rather large one. So, I'd like to address it before 
another flamewar begins.

-This problem already exists.
 There are many trivial USE-like flags in the various .mk files which 
change aspects of a package. The binary packages released by NetBSD 
are all built with the default settings. Major features (I can really 
only think of the gtk one atm) are handled with alternate package 
names, like: foo-gtk1 and foo-gtk2. If you want to build a foo 
package  differently then, you build from source and change settings 
via .mk infrastructure. Your binary package will be named the same 
but will differ.

-Using this extensively will expose the problem.
 By changing the major feature differences to use USE_* variables 
instead of naming conventions we expose a problem with the naming 
system. If we build package foo with PREFER_GTK2 it will be named the 
same as foo with GTK1. This can be solved with a Flavor-style 
feature. Basically, we _can_ use a flavor feature to label packages 
with their USE_* flags. If we set PREFER_GTK2 and FLAVOR_PREFER_GTK2 
(these is not hardcoded of course) then our packages built with GTK2 
(if supported) will label themselves foo-gtk2. Of course, if this 
flavoring where done by default we would have millions of 
combinations. The NetBSD official binaries will only turn on 
flavoring for major features such as gtk.

-Ultimately nothing will _really_ change.
 --Basically, the official binaries will keep their names and custom 
binaries will differ slightly (not a real problem)
 --With major subsets (like gtk) their names will not be set by 
package name but NetBSD will release two flavors by default (eg, 
editors/vim will produce vim-gtk1 and vim-gtk2 on release, by 

Nate Hill <>