Date: Fri, 8 Oct 1999 11:21:46 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Kris Kennaway <kris@hub.FreeBSD.ORG> Cc: Mike Meyer <mwm@phone.net>, freebsd-ports@FreeBSD.ORG Subject: Re: install newer version over old one... Message-ID: <19991008112146.A39653@rucus.ru.ac.za> In-Reply-To: <Pine.BSF.4.10.9910071612290.59180-100000@hub.freebsd.org> References: <Pine.BSF.4.10.9910070940540.24161-100000@guru.phone.net> <Pine.BSF.4.10.9910071612290.59180-100000@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu 1999-10-07 (16:28), Kris Kennaway 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.
The stuff after the last '-' is the version.
That is the way things are meant to work - if it doesn't, it's a mistake,
and needs to be fixed.
This is how pkg_version does its stuff, for example.
> 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).
We need a proper upgrade path, which is non-trivial.
gtk-1.1.1 and gtk-1.2.3 can co-exist, but netscape-4.6 is upgraded by
netscape-4.7.
docbook-* is another problem.
> 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.
This is really the only way to do it for complex ports, but we should have
a default "ALWAYS_UPGRADE" target, which simply says "no matter what
version you have now, this one will replace it perfectly".
This could work for netscape and a whole lot of others.
We could make things simple by having "UPGRADES= 1.*", which says if the
pkg version is currently 1.*, we can just upgrade to this. Apply with
1.2.*, and gtk-1.2.0 can be upgraded by gtk-1.2.12 with no problem.
More complex ports can set an "UPGRADE_SCRIPT" which should exit
0 for success, and 1 for failure, or something like that. We might
have to have some method that returns the list of ports that have
to be upgraded.
> How do these ideas inspire people?
I had some working upgrade stuff for simple ports, which did
REQUIRED_BY files, but it was only a few lines of code, and it got
hit by my recent fun with newfs. The simple stuff is simple, but
the complexity increases geometrically with problem ports (ie,
stuff that is actively developed - gtk/gnome/kde apps, &c.)
Of course, the real hard part is making this work for packages.
Neil
--
Neil Blakey-Milner
nbm@rucus.ru.ac.za
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?19991008112146.A39653>