General ports questions

[Ryan Schmidt]

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.