From owner-freebsd-ports Thu Oct 7 16:28:44 1999 Delivered-To: freebsd-ports@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 0A55014EEA; Thu, 7 Oct 1999 16:28:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id F16F61CD46A; Thu, 7 Oct 1999 16:28:42 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Thu, 7 Oct 1999 16:28:42 -0700 (PDT) From: Kris Kennaway To: Mike Meyer Cc: freebsd-ports@FreeBSD.ORG Subject: Re: install newer version over old one... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 7 Oct 1999, Mike Meyer wrote: > The DISTNAME information isn't any more help than the PKGNAME (what > it's using now) and would break proper interaction with the package > system. Python is typical: The way which springs to my mind is to separate the PKGNAME into two parts: PKGNAME and PKGVER: wibble-1.0 gets split into "wibble" and "1.0" I see three options for how to manage upgrading: 1) We leave things as they are in /var/db/pkg, and the make target matches against the subdirectories with ${PKGNAME}-*. This has potential problems with ports named foo and foo-devel, etc - you can't differentiate between a PKGVER of "devel-1.0" and a PKGNAME of "foo-devel" and "1.0". We could mandate that all PKGVERs start with a number, but it's still kinda icky IMO, and probably will fail to catch a number of corner cases. 2) We maintain a database of installed ports indexed by PKGNAME, so the upgrade target just pulls out the current installed version and forms ${PKGNAME}-${PKGVER} to remove. 3) We reorganise /var/db/pkg/${PKGNAME}-${PKGVER} to /var/db/pkg/${PKGNAME}/${PKGVER} and essentially get the above for free. Then we can do things like: checking for a pre-existing (older) version of the port at install-time, and either not installing over the top, proceeding anyway, or upgrading (remove old; install new). As previously mentioned, upgrading could generate a child dependency tree and optionally walk it, rebuilding the ports which depend on the one you have just upgraded. A set of upgrade targets in the port makefiles could be added to handle port-specific issues regarding upgrades. They could be passed the old version number, so the port can deal with known cases of backwards incompatability and advise how to proceed; do simple config-file munging (optionally), etc. This may not be used much, but it's potentially useful. How do these ideas inspire people? Kris ---- XOR for AES -- join the campaign! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message