Subject: Re: difficulty from renaming packages, and how to deal
To: Geert Hendrickx <firstname.lastname@example.org>
From: Greg Troxel <email@example.com>
Date: 09/21/2007 12:20:49
Geert Hendrickx <firstname.lastname@example.org> writes:
> But what with packages that have a differrent API or datafile format in
> newer versions? E.g. if apache-1.3.x or PostgreSQL 7.x get's EOL'd, I'd
> vastly prefer my update script to error out than to blindly update it to
> the latest version.
There are two separate issues lurking here, and I'd like to avoid
dealing with both of them.
1) Some upgrades can surprise people, and we should perhaps have a way
to obtain consent from the admin. apache 1.3 to 2 is certainly an
2) Sometimes directories are moved, and there is absolutely no point in
anything other than automatically tracking the move.
These two things come together when we start talking about moving
directories aroun as part of a "version Y is now the standard, and X
old, whereas yesterday X was standard and Y bleeding edge".
For dicussion, assume we have
foo-1.3 built from foo
foo-2.0 built from foo2
Now, when we rename foo to foo13 and foo2 to foo, that's saying that the
default upgrade path is to get foo-2.0. This is really the same thing
as updating foo from 1.3 to 2.0 without the multiple directories, and
that happens all the time.
I can see how a pkgid can be useful, but it seems like a lot of work to
maintain compared to the benefit. date and PKG_PATH is unique, or