Date: 08 Sep 2000 19:19:45 -0700 From: asami@FreeBSD.org (Satoshi - Ports Wraith - Asami) To: Neil Blakey-Milner <nbm@mithrandr.moria.org> Cc: Will Andrews <will@physics.purdue.edu>, FreeBSD Ports <ports@FreeBSD.org> Subject: Re: Ports Options Paper Message-ID: <vqcu2bq71dq.fsf@silvia.hip.berkeley.edu> In-Reply-To: Neil Blakey-Milner's message of "Sat, 9 Sep 2000 02:07:03 %2B0200" References: <20000903052226.E1205@radon.gryphonsoft.com> <200009082243.e88Mh9V05579@silvia.hip.berkeley.edu> <20000909020702.A64259@mithrandr.moria.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* From: Neil Blakey-Milner <nbm@mithrandr.moria.org>
* On Fri 2000-09-08 (15:43), 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)
*
* That doesn't make a difference at all (unless I'm missing something).
*
* ${PORTNAME}-${PORTVERSION} gives the same information as
* ${PORTNAME}/${PORTVERSION}. I've seen this suggested many times, and
* every time I say this, and then noone sends me a reply. I'm not against
* the change, but I don't see what it gives us.
No, you are right, it doesn't, as long as we ensure that
${PORTVERSION} (including revision and epoch) doesn't include a "-".
It will just make it slightly easier to find it, and with no confusion
whatsoever, that's all.
I also thought that if there is some information we want to store
about all (coexisting) versions of a port, we can put them in
${PKG_DBDIR}/${PORTNAME}/somefile. But I'm not sure what that
information will be, maybe everything is version-specific so this
doesn't matter.
* I'd much rather see some sort of commitment to support multiple versions
* 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.
* 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.
* 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.
* Also, some applications may be affected by a library bug, and others may
* not - so while gview needs gtk-1.2.5 with libgtk12.so.3, gftp will still
* work fine when you upgrade from it's initial gtk-1.2.3 to gtk-1.2.5,
* since it uses standard libgtk12.so.3 functions, and doesn't need
* recompiling.
I'm not sure what this has to do with virtual packages. If this
paragraph was supposed to go to the end of (1), then yes, I agree.
* 3) port-epoch and port-revision (which we should have soon, after kkenn
* took my cause over.) (for ports and packages)
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.
* 4) synchronized INDEXs from (possibly) multiple sources (for packages)
*
* This is necessary mostly for people who subsist on packages. We must
* know that if we upgrade to sawfish-0.38, we must upgrade to rep-gtk-1.3,
* &c. We also need to know if something that relies on rep-gtk-1.2 will
* need to be upgraded if rep-gtk-1.3 is installed. (This is hard, and is
* why virtual packages denoting shared libraries may be necessary.)
*
* Then we have to do it all backwards if they try use a CDROM, and then
* forwards again if they move to a closer mirror that is slightly out of
* date, &c.
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?
* 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.
Of course, splitting libgtk12 into multiple ports that install subsets
of items is going to be useful for package users and I'm all for it.
(XFree86-4 is (almost) done, so that's one big target down.) I'm just
not sure if we need any additional framework changes for it.
* 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. :<
* 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. :)
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?vqcu2bq71dq.fsf>