port upgrade

[Ryan Schmidt]

On Jul 13, 2009, at 20:55, Scott Haneda wrote:

> It is about time for me to learn about the port upgrade process.   
> My ASSP port file is complete, and working as far as installs go.   
> There may be some bugs in ASSP, or the perl modules, that I can not  
> figure out, but the port itself is solid.
>
> My next step is to make sure that upgrades are smooth.
>
> ASSP is a copy to install type of app, you unzip it, move the files  
> in place, and start it, that is all there is to it.  It comes with  
> a healthy list of perl dependencies, but as long as those are in  
> place, it works.
>
> MacPorts is largely in this case, being used to avoid the problems  
> a lot of mac users had with CPAN, and get all the perl bits in place.
>
> Largely, when ASSP is updated, only one file will be updated, which  
> is assp.pl, the core application for the proxy.
>
> My install essentially unpacks, and loops through all the files in  
> the distribution.  Some need removing, as they are windows  
> specific, some need reinplacing to change the perl chebang, and  
> some need some line endings patches up.
>
> ASSP comes with for example, a greylist.txt file, in it will be a  
> list of hosts that are to be excluded from greylisting.  There are  
> many other files that are like this, that is one example.  This  
> file is also assumed to be edited by the end user, either by hand,  
> or via the web admin that assp.pl provides.
>
> ASSP will create log files, I know that an port upgrade assp will  
> leave those alone, I believe even an uninstall will leave those  
> alone.  But what is the procedure for upgrades?  I would not want  
> greylist.txt touched.
>
> What happens if there is an introduction of a new file, that will  
> need to be copied in place?  What happens if there is an  
> introduction of a existing file that needs to be over-written?
>
> I am looking for suggestions on how to best make this a solid and  
> stable process for users of this port file.

During the destroot phase, your port must stage its files into the  
directory identified by the ${destroot} variable. Since ports should  
generally put things inside the MacPorts prefix, that means you will  
usually be copying things to some place under ${destroot}${prefix},  
e.g. a program the user is expected to run might be installed into $ 
{destroot}${prefix}/bin

During the install phase, MacPorts takes everything in the destroot  
and copies it to a location in ${prefix}/var/macports/software/$ 
{name} (in a directory named for the version, revision and selected  
variants)

During the activate phase, MacPorts makes hard links from the thing  
in ${prefix}/var/macports/software/${name}/... to the corresponding  
place in / and in the deactivate phase, MacPorts removes those hard  
links again.

So simply anything you put in the destroot will be registered to the  
port. If you uninstall or upgrade the port, the items that were  
registered to the old version of the port will be removed.

So you would not want to register configuration files or log files or  
the like to the port. Instead, you would register sample versions of  
the configuration files to the port, and either advise the user to  
make a copy of these files, or do so for the user upon first  
installation if they don't already have them. The whois port  
demonstrates the former strategy while apache2 shows the latter.