Date: Sun, 7 Jul 2002 23:56:10 -0400 (EDT) From: Garrett Wollman <wollman@lcs.mit.edu> To: drosih@rpi.edu Cc: arch@freebsd.org Subject: Re: Package system flaws? Message-ID: <200207080356.g683uA0v028226@khavrinen.lcs.mit.edu> In-Reply-To: <p05111745b94e9452f3b3@[128.113.24.47]> References: <20020706220511.GA88651@scoobysnax.jaded.net> <3D27A296.D58FB4B4@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <p05111745b94e9452f3b3@[128.113.24.47]> Garance writes:
>Separate from that, one thing I think we need is some mechanism
>which makes certain that the generated package-list for a port
>is exactly correct.
The ports-build cluster does that, but only for packages.
The problem stems mainly from the fact that, when you build a port
from source, you're not starting from a clean environment (unlike
bento). Many configure scripts will then glom onto whatever random
software you happen to have installed (``Gee! You seem to have emacs
installed! Wouldn't you like to play with my Emacs Lisp files?'') and
builds or installs extra stuff that doesn't make it into the official
package. Since bento never notices it, maintainers are not frequently
motivated to deal with the problem.
(I've run into this recently working on FreeRADIUS, which I've had to
instruct to build only static executables, with no loadable modules,
in order to deal cleanly with this behavior.)
The ports system really does not have a good way of dealing with
conditional dependencies (``I can use one of these if you have it'').
For many packages, there are simply too many possible combinations for
the maintainer to effectively test all of them. It gets even worse
when some packages depend on specific options of other packages (viz.,
GNOME needs libxml+Python but KDE and docproj do not).
There really isn't any good mechanism of supporting this -- there are
already too many ports which differ from another based only on the
setting of some option or other.
It would be nice to have a mechanism like the following (since we're
all expressing our wishlists here):
- Each port contains an enumeration of the possible variants and
on-off options. Some options might not make sense with all possible
variants, so the listing of options is per-variant. Some options
might not be compatible with each other, so there needs to be a way
to handle that as well.
(The distinction I'm making here is that a `variant' changes the
behavior of the resulting program or library, in such a way as other
programs or libraries using it might depend upon, whereas an `option'
simply causes additional files to be installed, which might or might
not add functionality.)
- Each variant must have a human-friendly short name and comment,
including the default variant. Likewise options, except that the
default state (which must be `off') does not have a name.
The whole thing can be referred to as:
$PORTNAME${variant+"-$variant"}${options+"+$(echo $options | tr ' ' '+')"}
- Whether building from source or installing a package, users are
required to explicitly select the variant of their choice.
If no variant is selected, the user gets a list of possibilities and
is invited to select one (and any options that might apply).
pkg_info options and make targets are provided for automatically
displaying this list without attempting to install.
- The package build cluster does combinatorial expansion on each port,
and builds provisional packages for all variants and permissible
option combinations. (Maintainers are encouraged not to go
overboard on this!)
(Here's the important new part, which would require a significantly
enhanced package format....)
- The package build cluster, having constructed all of the possible
combinations of options and variants, and having made provisional
packages of each one, runs a unification process across all of the
provisional packages to create a single ``fat'' package with
metainformation indicating which versions of which files are present
for which variant and option combinations.
This mechanism could also be used to create multi-architecture
packages, but in most cases the executables take up the lion's share
of the space so doing this makes little sense. The functionality
should be available, though, in case third-party package creators
wish to do so.
Possible Makefile syntax might look something like this:
VARIANTS= generic foo bar
COMMENT_generic= "Whatever pkg-plist used to say"
OPTIONS_generic= ipv6
COMMENT_foo= "Use the foo graphical user interface"
OPTIONS_foo= ipv6 quux:!ipv6
COMMENT_bar= "Use the bar graphical user interface"
COMMENT_ipv6= "Include support for IP version 6"
COMMENT_quux= "Build a loadable completion module for the quux shell"
.if "${VARIANT}" = "foo" || "${VARIANT}" = "generic"
.if "${OPTIONS:M/ipv6/}" != ""
PATCH_FILES+= ${PORTNAME}-ipv6-patch
.endif
.endif
.if "${VARIANT}" = "foo"
CONFIGURE_ARGS+=--with-libfoo
LIB_DEPENDS+= foo.23:${PORTSDIR}/x11/foo-lib
.if "${OPTIONS:M/quux/}" != ""
CONFIGURE_ARGS+=--enable-quux-completion
BUILD_DEPENDS+= ${PREFIX}/include/quux/complete.h:${PORTSDIR}/shells/quux::generic+dso
# depend specifically on the `dso' option of the `generic' variant of quux
.endif
.endif
.if "${VARIANT}" = "bar"
CONFIGURE_ARGS+=--with-libbar
LIB_DEPENDS+= bar.42:${PORTSDIR}/x11/bar-base::42
# depend on variant `42' of the bar-base package
.endif
OK, so that's a lot of work, and I'm not exactly volunteering. But it
would be very nice to have.
-GAWollman
--
Garrett A. Wollman | [G]enes make enzymes, and enzymes control the rates of
wollman@lcs.mit.edu | chemical processes. Genes do not make ``novelty-
Opinions not those of| seeking'' or any other complex and overt behavior.
MIT, LCS, CRS, or NSA| - Stephen Jay Gould (1941-2002)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207080356.g683uA0v028226>