Date: Fri, 8 Sep 2000 21:38:24 -0500 From: Will Andrews <will@physics.purdue.edu> To: Satoshi - Ports Wraith - Asami <asami@FreeBSD.org> Cc: Neil Blakey-Milner <nbm@mithrandr.moria.org>, Will Andrews <will@physics.purdue.edu>, FreeBSD Ports <ports@FreeBSD.org> Subject: Re: Ports Options Paper Message-ID: <20000908213823.F632@radon.gryphonsoft.com> 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, Sep 08, 2000 at 07:19:45PM -0700, Satoshi - Ports Wraith - Asami wrote:
> 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.
Multiple relative dependencies can do this. For example, a port that
needs QT 2.1.6 but can use QT 2.2.0, and cannot touch versions prior
to QT 2.0, or later than QT 2.2.1:
LIB_DEPENDS= qt-(2.1.5,2.2.0],(2.0,2.2.1):${PORTSDIR}/x11-toolkits/qt22
It's kludgy, but it can work. Just apply math. :-)
> 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.
See above.
> * 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.
But that's the nasty way to do it. Why not make a ${PKG_DBDIR}/virtual
file that lists the "virtual" packages installed, and add a VIRTUAL
variable that lists the virtual package(s) installed by a port?
> This is ready to commit. I'm just waiting for tg to import his
> bsd.python.mk so I can commit the latest bsd.port.mk with it.
He already did..
> I'm not sure what you mean by "synchronized INDEXs" but what you are
> talking here, isn't this what the NetBSD stuff is about?
Neil is talking about a centralized database where packages can find the
necessary upgrade information.. at least, that's what I remember from
the lengthy explanation he gave me.. Neil? :)
> * Not totally related, but we may need to explore NetBSD(?)'s piecemeal
> * packages (build port once, make multiple packages from the collected
> * bits). Debian does something like this, and provides libgtk12 with just
> * the shared library and run-time stuff, and libgtk12-dev, with the static
> * library and include files and developer stuff.
>
> Eek. That sounds too much like the xtt-* spaghetti. ;)
>
> Really, I don't think you guys should worry too much about packaging.
> The keyword here is "parallelization". I have a setup for i386 (and
> soon alpha) that builds packages in parallel so it really isn't much
> of an issue if a few of the large tarfiles have to be extracted
> multiple times. It is much more important (to me, at least) that the
> tasks can be parallelized easily, with no hidden dependencies or nasty
> surprises, etc.
What's wrong with the method he's suggesting? If you are worried about
clashing WRKSRCs, just see one of my previous emails. All that needs to
be adjusted is PKGNAME, and as long as the dependencies are satisfied, a
package can be compiled and generated.
In fact, it'd probably clean up a lot of the messiness involved with the
current XFree86-4-* ports, if all the various PKG{NAME,}s could be put
in the central XFree86-4 port like they should be.
Seriously, there are a lot of advantages to being able to build multiple
packages, especially in the manner he's talking about. The overhead
would likely be a couple bytes between the current "full package" and
the split-up "include headers" "libs" etc. packages. Again, since this
only matters as far as packages go, we only have to worry about what is
*INSTALLED*, not what is built. If, say, we want the headers and
nothing more, the build target can be skipped. And so forth.
> * 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. :<
Yes, that's certainly the problem.. :(
> * 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. :)
That's a good point, I suppose.. perhaps a USE_OPTIONS variable..
--
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?20000908213823.F632>