Date: Fri, 8 Sep 2000 18:28:33 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> 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: <Pine.BSF.4.21.0009081819050.78526-100000@freefall.freebsd.org> In-Reply-To: <200009082243.e88Mh9V05579@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Sep 2000, 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.)
I don't really see what matching ${PKG_DBDIR}/${PORTNAME}/ver* compared to
${PKG_DBDIR}/${PORTNAME}-* does, except adding more files. In either case
you have to parse a version string to determine whether it's old.
> (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.
The package should carry information about which versions of its parent
dependencies it works with - if they conflict, they must be upgraded too.
This has been implemented by NetBSD already.
Upgrading children is more difficult since a package generally wont know
what packages may depend on it, and until you fetch any new versions of
the children you wont know if they can co-exist with the parent and don't
need to be upgraded after all. Upgrading all children would be a
reasonable improvement over what we have now, and the ports index could be
used to infer the missing data if it's present (i.e. the ports index
carries the same information which would be obtained by fetching the
individual package and checking for a version conflict, so you can just
use that if it's up to date)
> 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. :)
Until/unless we build packages with multiple versions, packages will never
be enough for our users - if they want to use a feature which isn't built
into the default package, they have to venture into ports. We can't get
away with saying "ports are for experienced users only, everyone else can
use packages" (yet)
> * 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. :)
One more comment on this: your argument seems to be "well, no-one could
ever make it work before, so we should no longer try". I don't think
that's a valid argument.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
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?Pine.BSF.4.21.0009081819050.78526-100000>