Date: Thu, 7 Oct 1999 16:28:42 -0700 (PDT) From: Kris Kennaway <kris@hub.freebsd.org> To: Mike Meyer <mwm@phone.net> Cc: freebsd-ports@FreeBSD.ORG Subject: Re: install newer version over old one... Message-ID: <Pine.BSF.4.10.9910071612290.59180-100000@hub.freebsd.org> In-Reply-To: <Pine.BSF.4.10.9910070940540.24161-100000@guru.phone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9910071612290.59180-100000>