Subject: Re: Consistent "Optional Dependecy" handling
To: None <firstname.lastname@example.org>
From: Nate Hill <email@example.com>
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 bsd.pkg.defaults.mk? Is there some kludge that
> > needs changing elsewhere?
> bsd.pkg.defaults.mk 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
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 <firstname.lastname@example.org>