On Jan 26, 2009, at 20:17, Scott Haneda wrote:
So next on my list of quandaries is upgrades.
The last port for ASSP was 1.1.0, which is about 4 major releases
out of date. I am guessing, no one is using it, those old versions
just did not work well.
I have to accept there may be someone using 1.1.0 and come along
and issue a port upgrade, which with the way I have made my port,
is going to step all over their files. The entire directory tree
is different, it will break things for sure.
Why will your port step all over their files? If their files are
those that were installed by the port, then it is understandable; a
port should not include in its destroot files it is expected for the
user to modify. See the apache2 port for an example of how user-
modifiable configuration files should be handled (install template
copies of the files and instruct the user to make copies of them, or
make non-destrooted copies of the files for the user on the first
install).
The trouble is, it sucks to rename the port, and call it assp-new
or something like that. What is suggested here? Is there a way to
port check for the old version of a port, say, anything 1.1.0 or
earlier, and just bail out at that point? I think that would be my
best option.
I wouldn't make a new port or rename the existing port, since as you
said the existing port is for an ancient version that nobody is
likely to be using, and that nobody would want to use if the new
version is available.
If the old port installed a program called, say, "assp", and it has a
switch "--version" that returns its version number, then you could
run "${prefix}/bin/assp --version" in your port's pre-fetch phase and
bail if it's not a recent version. However, if a user did have the
old version installed, why wouldn't they want to upgrade to the new
one, which I assume works better?
How do upgrades work? When ASSP first runs, it makes about 5
directories, these contain logs, and data made by the app once
run. I can not mess with these on upgrade. There are also cfg
files as well, those need to be left alone.
MacPorts doesn't include directories in the destroot, so they won't
be touched, unless after uninstalling a port a directory becomes
empty, in which case MacPorts removes it. Use destroot.keepdirs if
you want to keep an empty directory.
Are the configuration files part of the destroot? If so, then on
upgrade, they will be removed or overwritten. As above, configuration
files the user is expected to modify should not be part of the destroot.
But, files may get retired, renamed etc, so I can not just put the
new files in the old place. Is it ok to copy the old directory, as
assp.bk or something, install, then pull the important files back
into the new update? Or is it best for me to find the diffs in the
update, and file by file make decisions?
I don't know that I would go to any such trouble. You could certainly
make a backup copy of the user's old configuration files as a
courtesy, but I would leave updating the configuration files to the
new format to the user to do. I don't know of any other port that
does this automatically for the user.
This is for an email server proxy, it is imperative that I test all
cases, this is not like wireshark breaking on someone. My sole
reason for this is for myself, and well as a pretty good handful of
email admins, most in large ISP installations, and can not have
downtime. Not all are going to dev stage this, and just go wild
with it, and while their fault, I want to be as careful as I can.
That does make things more difficult. But MacPorts does not currently
have a no-downtime guarantee or anything like that, so it really is
the responsibility of every MacPorts user to ensure the uptime of
their own system, by knowing what software they are upgrading and how
it interacts with the other software on their system and how to fix
configuration files for new versions of software. Sysadmins should
test new versions of software on a testing / staging server first
before putting it on a production system, and for the production
system they should have a strategy in place for reverting back to the
old version should that be necessary. "sudo port deactivate foo
@new_version && sudo port activate foo @old_version" can be part of
that strategy, but current backups are essential too.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
