port upgrade

[Scott Haneda]

Thanks for the other reply Bryan, I will combine my comments here,  
rather than opening an entirely new email, since they are so closely  
related.

On Jul 13, 2009, at 7:52 PM, Ryan Schmidt wrote:

> 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.
>>
>> [snip...]	
>
> [snip...]	
>
> 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.


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.

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.

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 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.

Is destroot.keepdirs really only for directories, or can it be applied  
to files as well?  Is that the preferred method here, to simply create  
a list of files I want to keep and iterate them with  
destroot.keepdirs?  This protects those files from any modification at  
all when performing upgrade or uninstall?

Or perhaps I do something like this:
post-activate {
     set keepers {list of files I want to keep}
     foreach keep $keepers {
         if {![file exists ${keep}]} {
           file copy ${keep} \
                ${assp_base}/${keep}
         }
     }
}

That is probably syntactically wrong.  I am not sure if that is right  
either, and it makes sense to me how that would deal with a new  
install, but not a upgrade, or a uninstall.

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?

Thanks for the guidance, I am almost there.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *