Date: Sat, 9 Sep 2000 04:45:44 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.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: <20000909044544.B67715@mithrandr.moria.org> In-Reply-To: <vqcu2bq71dq.fsf@silvia.hip.berkeley.edu>; from asami@FreeBSD.org on Fri, Sep 08, 2000 at 07:19:45PM -0700 References: <20000903052226.E1205@radon.gryphonsoft.com> <200009082243.e88Mh9V05579@silvia.hip.berkeley.edu> <20000909020702.A64259@mithrandr.moria.org> <vqcu2bq71dq.fsf@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri 2000-09-08 (19:19), Satoshi - Ports Wraith - Asami wrote:
> * of software that have to co-exist. Debian uses ssh-1.2.13 and
> * ssh2-2.1.0, libqt1-1.45 and libqt2-2.0.2, and similar package
> * identities, and concepts like "upgrades", "conflicts", and such.
> *
> * We need a subtle context of "streams" of programs so we know that
> * qt-1.45 and qt-2.0.2 can co-exist, and that qt-1.44 upgrades to qt-1.45
> * and not qt-2.0.2, &c. I'd suggest a (hopefully the final?) "stream"
> * number in the version number, if we're not willing to muddy the package
> * name with it. (I'm not too taken with muddying the package names, truth
> * be told)
>
> That is a good point. It doesn't necessarily have to go into the
> package name or version number, but we at least need the information
> in the package itself (and thus somewhere under ${PKG_DBDIR}) that
> tells our tools what is the correct upgrade path so we won't
> accidentally delete qt-1.45 when we're installing something that
> requires qt-2.0.2.
You're probably right here; it probably doesn't need to be externalized
in the package name.
> * 1) relative dependencies
> *
> * This is so we don't have to have a _perfectly_ up to date package system
> * constantly. Who cares if we have bash 2.1.3 or bash 2.1.4, unless we
> * know there's a problem in bash 2.1.3? (for packages, mostly, but I
> * wouldn't mind seeing it in ports too.)
>
> We need it for both. The ports dependency mechanism on relying
> basically on exact matches on filenames (this includes shared library
> versions) is simply not good enough in a lot of cases.
Ok, I'll be thinking about this one a bit.
I'll probably use:
RUN_PKG_DEPENDS= package:1.2<x<1.5:${PORTSDIR}/foo/package
BUILD_PKG_DEPENDS= package:1.2<x<1.5:${PORTSDIR}/foo/package
> * 2) virtual packages (for ports and packages)
> *
> * We don't really care if we have apache-1.3.12 or
> * apache-modssl-1.3.12+1.0.3, so long as we have apache. apache ports can
> * export virtual package 'virtapache-1.3.12', and something simple like
> * 'static-webserver-1.0.0' and 'cgi-webserver-1.0.2'.
>
> Actually, we *can* do this with the current framework -- just create a
> www/virtapache port that is basically empty and have all the apache*
> ports depend on it. Sort of like the kde or gnome meta-ports, just at
> the opposite end of the dependency chain.
I never thought of this. This would probably work great.
> * I wouldn't have minded this feedback 18 months ago when I suggested and
> * implemented it and got no response whatsoever.
>
> I'm sorry. I have a lot of things to do, and as noted in the
> "bikesheds and nuclear power plant" analogy, complex and well
> thought-out proposals are also the hardest to comment on. :<
The main problem is that I felt basically finished with the first
iteration, and ready to pounce on the thing, and I had no way to put it
into the system, since (for some excellent reasons) you're the
architectural arbiter in these things.
> * I agree, but porters are going to have to get used to looking for
> * options files. But we should probably write tools that will remind them
> * and ease it for them.
>
> I guess, but I suspect most ports will not have files/options, while
> many of them have *_DEPENDS, so I prefer to keep normal dependencies
> in the main Makefile. (See, this is an inode issue too. :)
With Will on a mission, I'm sure even /usr/ports/misc/more will have
options :>
Hey, isn't it about the time of year to suggest we cut down inode usage?
(:
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
nbm@mithrandr.moria.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?20000909044544.B67715>