Date: Fri, 8 Sep 2000 18:21:20 -0500 From: Will Andrews <will@physics.purdue.edu> To: Satoshi - Ports Wraith - Asami <asami@FreeBSD.org> Cc: Will Andrews <will@physics.purdue.edu>, FreeBSD Ports <ports@FreeBSD.org> Subject: Re: Ports Options Paper Message-ID: <20000908182120.C169@radon.gryphonsoft.com> In-Reply-To: <200009082243.e88Mh9V05579@silvia.hip.berkeley.edu>; from asami@FreeBSD.org on Fri, Sep 08, 2000 at 03:43:09PM -0700 References: <20000903052226.E1205@radon.gryphonsoft.com> <200009082243.e88Mh9V05579@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 08, 2000 at 03:43:09PM -0700, Satoshi - Ports Wraith - Asami wrote:
> (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.)
Simple enough.
> (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.
I'd prefer to set things up for the normal behavior, then make hacks
that account for unusual behavior. It's not like the new system I'm
proposing wouldn't allow for that. And it's not like we wouldn't
already have to use hacks to make them work in the current system.
The idea here is to streamline things for ports that do follow the
standard, to make it easier to maintain *THOSE* ports. The ones that
continue to be difficult will just continue to be difficult. The net
gain is additional maintainability for the 90%+ that DTRT.
> 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.
So make a command to show the dependencies? :)
> * 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.
Not really. Porters will not be required to set this up. I just want
some glue in the tree to allow people to do it this way.
> 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.
Well sure, for packages thats great. But I want the same functionality
in ports. Just because the functionality's there doesn't mean we'll
require people to use it.
> But maybe that's why you and I are writing this and the other 999,900
> FreeBSD users are not. :)
We only have 999,900 users?? ;)
I'd wager we have several thousand people who use only ports, and that's
enough to justify putting this code in the tree. As I said in the
original post, I'll be happy to do the majority/all of the code. ;)
So where's the problem? ;>
> * 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. :)
Not in the time I've been around. I've never heard of an attempt to
implement this sort of thing. Just because it didn't work the first
time doesn't give you the right to say this to me, or to deny a chance
for anyone's proposals to solve this problem.
In any case, if there is some thread on -ports I can examine to find out
what happened, that would be great. Repeating history is not something
I intend on doing, but instead to solve the problems.
--
Will Andrews <will@physics.purdue.edu> <will@FreeBSD.org>
GCS/E/S @d- s+:+ a--- C++ UB++++$ P+ L- E--- W+ N-- !o ?K w---
O- M+ V- PS+ PE++ Y+ PGP+>+++ t++ 5 X+ R+ tv+ b++ DI+++ D+
G++ e>++++ h! r- y?
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?20000908182120.C169>