Date: Sat, 5 Feb 2000 14:08:21 -0800 From: Jeremy Lea <reg@FreeBSD.ORG> To: Ade Lovett <ade@lovett.com> Cc: Chuck Robey <chuckr@picnic.mat.net>, ports@FreeBSD.ORG Subject: Re: Multiple identity ports (was Re: gd requiring X) Message-ID: <20000205140821.B97935@shale.csir.co.za> In-Reply-To: <20000204104451.C17224@lovett.com>; from ade@lovett.com on Fri, Feb 04, 2000 at 10:44:52AM -0600 References: <20000203162952.B15558@lovett.com> <Pine.BSF.4.21.0002040014490.23833-100000@picnic.mat.net> <20000204104451.C17224@lovett.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Fri, Feb 04, 2000 at 10:44:52AM -0600, Ade Lovett wrote:
> It's not an inherently scalable idea for everything, I don't know what
> is, especially for those ports that (a) have a large number of optional
> dependencies, and (b) worse still, those that do (sometimes very
> subtle) different things at ./configure time depending on what you
> already have installed.
>
> In the (a) case, we have to make a tradeoff between the number of
> different ports/packages and the amount of bloat on the CD, in the
> ports tree, etc. Certainly, for a large "o" (optional dependencies),
> the [sum(nCo) n=0..o] is likely to be huge. Perhaps in this case we
> simply build a minimal and maximal case, and tell the end-user that
> there are other options at make or pkg_add time.
There are two kinds of ports like this in the tree. There are ports
like a lot of the GNOME stuff, and things like mutt and ispell, which
have flags in their Makefiles. Then there are ports like apache13-php3
or apsfilter, where you have a dialog based selection of what to turn
on or off.
I'm only trying to deal with the first kind, through the very basic
mechanism of testing if the needed files are already installed during
port building. During package building the port itself will still have
to make an intelligent set of defaults.
For the second type, the port still has to have an intelligent set of
defaults for package building, and we could add port build time logic
which turns on support for various features (ie prechecks their box) if
the needed files are found.
I think people are wildly over estimating the number of additional
pacakages. So far I think there would be about 30 new packages between
all of the stuff that I'm doing. These are ports which change their
behaviour based on some installed software.
xmms might be a good example. It has the ability to use GNOME if it
is installed. This is a change in it's behaviour, and under my scheme
results in an xmms-gnome-0.9.5.1 package. It also has the ability to
have a lot of plugins which can support various input and output
functions. Esound is one of them. If ESound is installed, you want it
to build an ESound output plugin. If it's not then you dont. In this
case, you want the xmms-0.9.5.1 package to not include ESound support,
but the xmms-gnome-0.9.5.1 package to include support.
I have yet to find one port with more than two behaviours, from the
current ports I've converted. timidity++, nessus and nmap are a few
though. These behaviours are mutually exclusive. ie you want to build
timidity++, timidity++-gtk or timidity++-motif but not
timidity++-gtk-motif. This works under the assumption that people are
looking for a uniform look and feel.
> (b) cases need to be fixed. The most obvious problems that I've seen
> so far (because I happen to be closest to it :) are those ports that
> have optional dependencies on GTK/GNOME with a USE_* variable, but
> don't do the right thing if GTK/GNOME is installed, and the USE_*
> variable is _not_ set. I don't understand enough about Jeremy's
> work yet to know whether this issue can be resolved easily.
I've fixed most of these ports. The really big issue here is that we
pass --datadir=${PREFIX}/share/gnome to GNOME enabled ports, which means
that they change the installed location of data files depending on if
GNOME is enabled. This makes lots of extra work, particullarly since
the GNOME people, as you know, don't think very carefully about
alternate directory layouts... My current felling is that we should let
the GNOME ports win and revert to their directory layout.
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000205140821.B97935>