port upgrade

[Ryan Schmidt]

On Jul 17, 2009, at 14:01, Scott Haneda wrote:

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

The tcl equivalent of the command line's "chmod" command is the "file  
attributes" command. There are several ports that use this so I would  
grep through the portfiles to find an example to follow.


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

You're doing it already in your port:

      if {![file exists ${assp_base}/assp.cfg]} {
           file copy ${assp_base}/assp.cfg.defaults \
                ${assp_base}/assp.cfg

I now recall the discussion weeks ago on the list wherein this bit  
was added to the port.

So in the above code, the assp base directory will contain both  
assp.cfg.defaults (which is registered to the port and which the user  
does not modify but which serves as documentation for the user as to  
what the defaults are), and assp.cfg (which the assp software  
actually uses and which the user modifies as needed).

Why is it a problem to have .sample files in /etc or anywhere?


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

As I said, the destroot cleanup code removes empty directories  
anywhere in the destroot directory. If a directory contains any file  
of any name, the directory will not be removed. So there's nothing  
special about the .turd name. A file by any other name would have the  
same effect.

.DS_Store files get created when you do certain operations on a  
directory in the Finder. Since nobody is browsing the destroot  
directory in the Finder while the destroot phase is  
running, .DS_Store files won't get created in there and won't be a  
problem.

If you do manage to create .DS_Store files in the destroot directory,  
you can cause problems. To test this, I just modified the zlib port  
to sleep for a minute in post-destroot, to give me a chance to fiddle  
with the destroot directory in the Finder. I changed to list view and  
played with the width of the columns to create a .DS_Store file.  
After the 60-second timeout, MacPorts told me about the mtree  
violation caused by the .DS_Store file.

--->  Fetching zlib
--->  Verifying checksum(s) for zlib
--->  Extracting zlib
--->  Applying patches to zlib
--->  Configuring zlib
--->  Building zlib
--->  Staging zlib into destroot
sleep 60
Warning: violation by /.DS_Store
Warning: zlib violates the layout of the ports-filesystems!
Warning: Please fix or indicate this misbehavior (if it is intended),  
it will be an error in future releases!

If I fiddled with a subdirectory, I could create a .DS_Store file in  
a subdirectory, for example in /Applications or /usr.

If I did such fiddling with multiple ports, the second port would  
complain on activation that it could not copy the .DS_Store in place  
because it already existed and was registered to the first port.

So, don't fiddle with the destroot directory in the Finder while the  
destroot phase is running and you won't cause the problem. :)


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

Line 109 says "configure {}". You should use "use_configure no"  
instead of "configure {}" as lint says.

Your portfile already says "use_configure no" on line 41 so you can  
just delete line 109 completely.


> 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}?

Sure, that would work.