From owner-freebsd-ports Fri Sep 8 19:20: 8 2000 Delivered-To: freebsd-ports@freebsd.org Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by hub.freebsd.org (Postfix) with ESMTP id C75FA37B506 for ; Fri, 8 Sep 2000 19:20:03 -0700 (PDT) Received: from silvia.hip.berkeley.edu (sji-ca14-01.ix.netcom.com [205.186.215.1]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id WAA20857; Fri, 8 Sep 2000 22:19:52 -0400 (EDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.11.0/8.11.0) id e892Jnw06461; Fri, 8 Sep 2000 19:19:49 -0700 (PDT) (envelope-from asami) To: Neil Blakey-Milner Cc: Will Andrews , FreeBSD Ports Subject: Re: Ports Options Paper References: <20000903052226.E1205@radon.gryphonsoft.com> <200009082243.e88Mh9V05579@silvia.hip.berkeley.edu> <20000909020702.A64259@mithrandr.moria.org> From: asami@FreeBSD.org (Satoshi - Ports Wraith - Asami) Date: 08 Sep 2000 19:19:45 -0700 In-Reply-To: Neil Blakey-Milner's message of "Sat, 9 Sep 2000 02:07:03 +0200" Message-ID: Lines: 134 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * From: Neil Blakey-Milner * 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