Date: Fri, 8 Sep 2000 15:43:09 -0700 (PDT) From: asami@FreeBSD.org (Satoshi - Ports Wraith - Asami) To: Will Andrews <will@physics.purdue.edu> Cc: FreeBSD Ports <ports@FreeBSD.org> Subject: Re: Ports Options Paper Message-ID: <200009082243.e88Mh9V05579@silvia.hip.berkeley.edu> References: <20000903052226.E1205@radon.gryphonsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* From: Will Andrews <will@physics.purdue.edu>
Hi,
Sorry for the late reply. I've (finally!) managed to read your paper
and here are my comments. First, general thoughts:
(1) The support infrastructure for something like you propose is not
there yet. For one thing, we need to move from ${PKG_DBDIR}/${PKGNAME}
to ${PKG_DBDIR}/${PORTNAME}/ver${PORTVERSION} (or some such)
before we can start talking about automated updates. With the
current system, we don't even know where the old version of the
port lives. (We can make some guesses by modifying the directory
name like pkg_version does, but really there should be no chance
for confusion.)
(2) Speaking of updates, we first need to implement updates. There
are lots of sticky problems, such as what to do when a port in the
middle of the dependency chain is updated (do we update all ports
that depend on this one as well as all ports that this ports
depend on?), etc.
Next, specific comments.
* The reasons for putting such things in a separate file is to
* simplify parsing for GUI-style programs like gportconf (which
* nbm proposed using with his XML format) or dialog(1), which
* would be the default user-friendly interface. It would also
* reduce clutter in port Makefiles somewhat.
That is a good idea.
* The *_DEPENDS can also be moved to ${FILESDIR}/options:
*
* LIB_DEPENDS= kdecore.4:${PORTSDIR}/x11/kdelibs2
* RUN_DEPENDS= konqueror:${PORTSDIR}/x11/kdebase2 \
* kjumpingcube:${PORTSDIR}/games/kdegames2 \
* kdf:${PORTSDIR}/misc/kdeutils2 \
* kword:${PORTSDIR}/editors/koffice \
* kppp:${PORTSDIR}/net/kdenetwork2
I'm not sure about this. I'd like to keep enough information in the
Makefile so people working on ports don't have to check many files to
figure out just what the port does.
* Returning to the idea of interfaces and that of storing info
* about a port's options: If a user selects a particular option,
* the package generator will note it in the ${PKG_DBDIR}/${PKGNAME}/+OPTS
* file. I.e., if GTK support is optional but not required and the
* user selects it, the package generator will put it in the +OPTS
* file as "WITH_GTK". If, say, a port supports Qt, GTK, and GNOMELIBS
* interfaces, it could hold "WITH_GTK,WITH_QT,WITH_GNOMELIBS".
Ok.
* Now let us address the fact that some configure scripts like to assume
* that if you have something installed and it finds it, it should use it
* while linking programs etc. This skews our package dependency system
* in a number of subtle ways. Thus, we should have a make.conf variable,
* USE_GRATUITOUS_DEPENDS, which we can check to see if it is allowed or
* not. Then, we can add something like this to a port that allows buidling
* with GTK but doesn't require it:
*
* option WITH_GTK
* LIB_DEPENDS= gtk-1.2.8:${PORTSDIR}/x11-toolkits/gtk12
* option GRATUITOUS
* SOME_VAR_TO_DEFINE_HERE= blah
* CONFIGURE_ARGS= --blah3 --blah6
* end GRATUITOUS
* option NO_GRATUITOUS
* GRATUITOUS_PATCHES= patch-aa patch-ac patch-zb3
* CONFIGURE_ARGS= --blah --blah2
* end NO_GRATUITOUS
* end WITH_GTK
*
* Where GRATUITOUS_PATCHES will be a string containing the names of the
* patches to be applied if USE_GRATUITOUS_DEPENDS is not defined (i.e. if
* it is necessary to apply patches etc. NOTE: I'm not real solid on any
* of these ideas, but this issue needs to be addressed in a satisfactory
* manner, to prevent package dependency breakage. The above method seems
* to be good enough to take care of 99.99% of gratuitous pkg dependencies.
* My major concern would be regarding conflicting patch files. Perhaps
* patchfiles for GRATUITOUS stuff should be denoted in a different manner.
We can certainly do this, but I'm not sure if we really want to go
this far. This is a tremendous amount of burden on porters.
I think Steve said it well when he suggested maybe we should
concentrate on packages for end-user use. The chrooted package build
system will not allow these kind of gratuitous dependencies to creep
into packages any more. (You said you always use ports. I do too.
But maybe that's why you and I are writing this and the other 999,900
FreeBSD users are not. :)
* Another issue that I've stumbled across over time has been the inability
* of a single port to create multiple packages. Hence, I'd like to reintroduce
This is not a good idea. We've tried it before, and it was a
disaster. The current MASTERDIR has come out of the smoldering ashes
of failed attempts to create a framework to build multiple packages
from the same directory.
"One package per port" is the First Principle of the Ports Collection
for a good reason. :)
Satoshi
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?200009082243.e88Mh9V05579>