port upgrade

[Ryan Schmidt]

On Jul 13, 2009, at 23:39, Scott Haneda wrote:

> It seems there is a pretty strong desire to put config files into / 
> opt/local/etc or equivalent.  I can see that being the case with  
> apache, or bind, and other software that generally works with that  
> in mind.

Yes, config files generally go in ${prefix}/etc. Note that apache2  
actually has its config files in the nonstandard location ${prefix}/ 
apache2/conf; I don't generally recommend creating new ports that  
ignore the ${prefix}/etc convention. A subdirectory of ${prefix}/etc  
would of course be fine, and appropriate if there are multiple config  
files.


> ASSP is a self contained application, with files, that loosely can  
> be called config files. They can not be moved, that would require a  
> lot of patching to the ASSP software, and would imo, create  
> confusion to the end user.  MacPorts is largely being used in this  
> case take take advantage of installing several p5's, the fact it  
> installs ASSP, is almost a nicety.
>
> I think the only way to explain this so I get it right, it to step  
> through it, bare with me on the length of this email...
>
> ASSP ends up living in /opt/local/var/ASSP/
>
> Installed files:
>      assp.cfg
>      assp.cfg.defaults
>      assp.pl
>      docs/
>      errors/
>      files/
>      images/
>      logs/
>      move2num.pl
>      notes/
>      notspam/
>      okmail/
>      pb/
>      quarantine/
>      rebuildspamdb.pl
>      reports/
>      spam/
>      stat.pl
>
> assp.cfg needs to never be touched by ports once installed.

Then don't copy it into ${destroot} in the destroot phase; copy it  
from assp.cfg.defaults directly into ${prefix}/wherever in the post- 
activate phase.


> According to the docs, an update is to do the following:
> - invalidptr.txt
> - URIBLCCTLDS.txt
> - nodelay.txt (merge)
> - redre.txt
> - ipnp.txt (merge)
> - blockreportuser.txt
> - validptr.txt
> - bombre.txt (merge)
> - whiteorg.txt (merge)
> - strictspf.txt (merge)
> - invalidhelo.txt
>
> So the non merge, are safe to replace, the merge are not.  In these  
> cases, if I could simply let ports replace them, and as long as a  
> backup of the entire /opt/local/var/ASSP directory was made, I  
> would be happy with that and a UI message that said which files  
> needed to be merged.
>
> * By merge, they mean, append your changes to the file.  I would  
> rather not get in the business of teaching ports how to merge those  
> files, and leave that to the user.
>
> There are some other cases, but understanding how to deal with  
> these should suffice.  If I can rely on new files that were made  
> after assp was installed staying untouched, then the app generated,  
> and user generated data is safe.
>
> It looks to me, like I have a limited set of files I need to make  
> sure are not touched by ports.
>
> The idea of registering these files as .sample files, and asking  
> the user to change them, completely destroys the way that ASSP is  
> designed to work.

I don't understand why; it's exactly the solution to your problem. In  
the destroot phase, don't install a nodelay.txt; instead, install a  
nodelay.txt.sample. Then, in post-activate, copy nodelay.txt.sample  
to nodelay.txt and tell the user about it. Or, if nodelay.txt already  
exists, tell the user to merge in changes from nodelay.txt.sample.  
See the php5 port for an example of this. (Well, I don't copy the  
file for the user, but I do tell them to either copy it or merge it  
depending on whether the file already exists or not.)

> I would consider them more preferences, than config files, and with  
> any preference file, it will contain some defaults, be written to  
> by the user, and should not be messed with on uninstall of an app,  
> and only sometimes modified on upgrade, if a format changes.

I don't see the distinction between a preference file and config  
files. Whatever you call it, they are files containing data unique to  
the user and should not be overwritten by MacPorts on upgrade.  
Therefore, don't register them to the port as part of the destroot.

> Is destroot.keepdirs really only for directories, or can it be  
> applied to files as well?

Yes, destroot.keepdirs is only for directories. It has no meaning for  
files.

The destroot phase works as follows:

First, MacPorts creates the ${destroot} directory and a bunch of  
empty directories inside it for the various places ports are likely  
to install files. Basically the entire hierarchy, such as ${prefix}/ 
bin, ${prefix}/include, ${prefix}/lib, ${prefix}/share/man, etc., is  
created for you, so that you don't have to make these directories  
manually in the destroot phase of every port.

Next, the pre-destroot, destroot, and post-destroot phases run,  
during which your port is to put files into the right places within $ 
{destroot}.

Finally, MacPorts removes any empty directories in ${destroot}.

If there are directories you would like to keep, even though they are  
empty, you use destroot.keepdirs, in response to which MacPorts  
creates a .turd_${name} file in each directory. Thus, when MacPorts  
gets to the part where it removes empty directories, it will not  
remove these "kept" directories, because they are not empty, because  
they contain a file (the .turd_${name} file).

> I think what I really want to do, is just unregister a list of  
> files form the port after the first time it is installed.  Maybe  
> there is a way to trick ports into doing this by copying a file in  
> during a certain phase but just keeping the name the same?
>

I can only reiterate: if you put the file in the ${destroot}  
directory during the destroot phase, the file is registered to the  
port. If you don't want the file registered to the port, don't do that.