ASSP out of date

[Ryan Schmidt]

On Nov 7, 2008, at 20:49, Scott Haneda wrote:

> Is there a long standing debate on this list that a normal reply  
> does not go back to the list?  I am sorry to all of you who I have  
> replied to direct, I did intend for it to go to the list for the  
> benefit of the archives.

Press the Reply All button in your email program to reply to the list  
and the sender.

Press the Reply button to reply only to the sender.

Generally you'll want to use the Reply All button.


> On Nov 6, 2008, at 1:06 AM, Bryan Blackburn wrote:
>> What goes in there of course depends on how you actually install  
>> this port;
>> since you've done this by hand you should have a pretty good  
>> idea.  Though
>> note everything should go into things starting with ${destroot}$ 
>> {prefix} as
>> that is a staging area, so port can then scan it to find all files to
>> install.
>>
>> For a manual install, see as an example the destroot phase of
>>
>> <http://trac.macports.org/browser/trunk/dports/math/ent/Portfile>
>>
>> to at least get you started.  If you have to install a number of  
>> files
>> matching various patterns, see the last part of the post-destroot  
>> phase in
>>
>> <http://trac.macports.org/browser/trunk/dports/archivers/lzo2/ 
>> Portfile>
>>
>> which uses glob to match multiple files.
>
>
> Yes, these are just files, which is the part in the script that I  
> am at now.
>
> First, there is the issue of needing to do things to the files  
> while they are freshly unpacked.  I am yet to find a good way to  
> recursively act on a set of files in TCL.

[snip]

There is a function fs-traverse in MacPorts designed for this. Grep  
through the existing portfiles to see how this can be used.


> How does one decide where to put the final set of files?   
> Currently, it looks like the old assp puts it in /opt/local/var but  
> how was that decided?  Do I hard code that path, or is there a  
> built in I am missing?

The /opt/local part should be expressed as ${prefix} in the Portfile  
since MacPorts could be in a different prefix. The /var part would be  
hardcoded. I don't know what kinds of files assp installs so I can't  
advise where they should go. The authors of assp don't have a  
recommended standard install location?


> The old assp port file did some user and group adding, and I have  
> never done that in the past to make this run. Is this a requirement  
> to do so, or at least a good practice?  I will check with the  
> developer, but I think the permissions are best set to the user  
> that installed it.  Or in the OS X case, the logged in user I would  
> assume. I can not see why this set of files needs to run as  
> anything else, it has it's own http server, so permissions and user/ 
> group, as long as the same as the http server, would be fine.

I dislike ports that mess with my system users and groups. For one  
thing, that means the port has to be installed as root; I prefer to  
install as my own user whenever possible. If a user/group is  
necessary for the software, then of course add it. If not, don't.


> In the old assp port I also see basically, once line of xinstall  
> for every file that needs dealing with.  Is there not a way to  
> simply tell it to take a directory, and move it where it needs to  
> go?  if not, what about the subdirectories, I have to move the  
> individual files one at a time, and then how do I create those  
> files parent directory?

You can use "file copy" instead of "xinstall" to copy entire  
directories.


> Finally, after all that, I will get to the dependencies, for which,  
> about 25% of them do not seem to have port files.  From looking  
> over many of the p5-* ports, is it really as simple as that, sort  
> of like CPAN does it, MacPorts does that as well, so I simply make  
> this bare minimum port file, and it runs with it? What happens if  
> this newly made port file has dependencies, and those dependencies  
> have dependencies?  Do I have to traverse the entire dependency  
> tree to get them to work?  I could be in those for 20 or so port  
> files if that is true :)

Make ports for those perl modules do not exist. Yes, you need to  
properly express each port's dependencies.