Date: Sun, 22 Feb 1998 10:58:48 +0100 From: Stefan Esser <se@FreeBSD.ORG> To: Warner Losh <imp@village.org>, "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: ports@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG> Subject: Re: make install Message-ID: <19980222105848.49897@mi.uni-koeln.de> In-Reply-To: <199802220424.VAA27120@harmony.village.org>; from Warner Losh on Sat, Feb 21, 1998 at 09:24:37PM -0700 References: <23951.888111289@time.cdrom.com> <199802220424.VAA27120@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1998-02-21 21:24 -0700, Warner Losh <imp@village.org> wrote:
> In message <23951.888111289@time.cdrom.com> "Jordan K. Hubbard" writes:
> : Probably the only truly non-hostile way of handling it would be to
> : give each subsequent version of a port an "upgrade" hook which would
> : do very specific and specialized things to upgrade it, removing only
> : those components which were known to be dreck in the new port and
> : selectively upgrading other components as necessary (each component
> : also having its own semi-intelligent update procedure). In other words,
> : try to encapsulate the kind of work that an expert user would do by
> : hand in upgrading the port. But that's also a lot of work. :-(
>
> Heck, I'd by happy with a warning and/or an option to remove the old
> port before installing the new.
>
> However, that, as you said, has its own problems. the ssh host key is
> currently spammed on each new install, which is an annoying problem :-(.
Automatically upgrading a port is very hard to do, since we'd
either have to limit from which version you can upgrade (making
it a multi-stage procedure to upgrade from an arbitrary version)
or to have a matrix of versions and procedures (maintenance
nightmar, will never work in reality).
Bit there is a low-tech approach, which makes you do the real
work of fixing up config files, but at least provides you with
the necessary input (by leaving the old files in reach :)
How about a prepare-install target, which does the following:
- verify the files' MD5 against pkg/+CONTENTS and tag <P> changed files
- compare pkg/+CONTENTS with the new version's PLIST and tag <D> files
that are only in +CONTENTS
- compare pkg/+CONTENTS with the new version's PLIST and tag <C> files
that are only in PLIST but do already exist; those files will be
overwritten, but apparently have not been part of the old version!
The tags could be implemented by files in ${WRKDIR}: ".dopreserve",
".dodelete" and ".conflicts". A non-empty .conflicts might either
be treated identically to ".dopreserve" (but that's NOT a good idea,
IMHO) or will make the installation fail, before any file has been
touched.
In very rare cases it might be good to be able to adjust those file
lists. (I guess there should be an option to put override entries
in pkg/dopreserve and pkg/doremove, or have some new tags defined
for PLIST, which will take care of this.)
As part of the install target (but not reinstall ?) the default
behaviour should be:
- abort with explanatory message (incl. file names), if .conflicts
is not empty
- delete files mentioned in .dodelete
- rename files mentioned in .dopreserve
(append suffix, e.g. OLD or even OLD.$oldrev or OLD.$timestamp)
In order to have this to work with packages, we need to implement
a similar functionalty in pkg_add. There could be hints in +CONTENTS,
using the same tags as might be added to PLIST for the port.
The result is, that with no extra effort for the ports maintainer:
- accidental name clashes will be noticed
- no stale files will be left over
- all modified files will be preserved, whether they seem to be
of relevance to the new port or not.
After checking out the new port and before the "make clean" in
the port's directory, a clean-installed target could be useful
to remove those OLD files.
I don't think an implementation would be that hard ...
Too bad I'm overloaded with other work already ...
Regards, STefan
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?19980222105848.49897>