port upgrade

[Scott Haneda]

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

This is good to know, I was just not aware of this method.  How do I  
set permissions when in this phase, I assume doing so with the ports  
commands will register it?

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

Ahh, ok, I understand now.  Can that copy of .sample to rename to real  
file name be avoided?  Can I just copy it in as it is named and be  
done with it?  I do not want .sample files hanging out in /etc in this  
case.

Sorry about all this, I was just totally unaware this was even a  
possibility.

> Or, if nodelay.txt already exists, tell the user to merge in changes  
> from nodelay.txt.sample.

Of the files, some are to be merged, some are to be replaces.  This is  
good actually, as it gives me a place to tell the users where the  
files are.  Perfect.

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

Thanks, will look into that port.

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

Understood.

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

Does this ever become an issue with .DS files getting in there, and  
that would prevent proper ports operations?  Or is it only .turd files  
that prevent the deletion of a dir?  I know a real non leading dot  
file will prevent it, and I expect that, but a .* file other  
than .turd, how is that covered?

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

Cool, thanks, this will work.

http://dl.getdropbox.com/u/340087/Drops/07.17.09/Portfile-dea0db16-115619.txt
$port lint
--->  Verifying Portfile for ASSP
Warning: Line 109 should say "use_configure no" instead of declaring  
an empty configure phase

Is that a big deal?  Will I have any issues with just following those  
instructions?  I think I tried and it did not like the use_configure  
command.

I will be installing my own custom launchd item, and not using ports  
for this.  I have never done this, do I just make a dir called "files"  
and put whatever I want in there? I can reference it with {filesdir}?

Thank you.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *