ASSP out of date

[Scott Haneda]

On Nov 11, 2008, at 4:10 PM, Ryan Schmidt wrote:
> On Nov 11, 2008, at 17:43, Scott Haneda wrote:
>> On Nov 11, 2008, at 1:57 AM, Bryan Blackburn wrote:
>>> On Tue, Nov 11, 2008 at 01:20:51AM -0800, Scott Haneda said:
>>>> Hello, had some more spare time this evening, working on the assp  
>>>> port,
>>>> thanks to all who are entertaining me in this training process.
>>>>

[...]

>> I do not at all understand that.  I want assp to end up in /opt/ 
>> local/var/ASSP so unless file copy does something special to a  
>> destination path, I am lost on that one.
>
> "file copy" does nothing special.

if file copy is more or less the same as
`cp source destinaction` on *nix, I may be at a loss here still.

> What is special, in a way, is the destroot and install phases.
>
> In the destroot phase, the port puts everything it wants to install  
> somewhere under ${destroot}, usually under ${destroot}${prefix} as  
> Bryan said.
>
> Then in the install phase, MacPorts (with no special instructions  
> from the portfile) copies everything from ${destroot} into /
>
> (That's a simplification that is only actually true in direct mode,  
> which is not the default and not really recommended. In image mode,  
> what actually happens during the install phase is that everything  
> from ${destroot} gets copied into ${prefix}/var/macports/software/$ 
> {name}/${version}_${revision}. Then the activate phase runs, which  
> makes hardlinks from there into /.)
>
> The whole purpose is for MacPorts to be able to track what a port  
> installs, so that things like "port contents" and "port uninstall"  
> work right.

I sort of figured this is part if a "receipts" system in order to keep  
a index of what is where and how to deal with it.  I still fail to  
understand... Sorry...

command      source           destination
file copy "${worksrcpath}" "${destroot}${prefix}/var/ASSP"

I get the source, that is where the files are.  So am I getting hung  
up on an issue in that destroot, is not as the name marginally implies  
to me, the final destination?  destroot is simply a temporary, for  
lack of a better word, location where macports will stuff something.   
When macports finished up, I assume some other action is done, in  
which it moves it to /opt/local/var/assp in this case?

If I run sudo port install assp now, with the in progress port I am  
dealing with, this command:
file copy "${worksrcpath}" "${prefix}/var/ASSP"
will end up with ASSP at /opt/local/var/ASSP which is where I want it.

I would guess, unless some magic happens behind the scenes, if I run:
file copy "${worksrcpath}" "${destroot}${prefix}/var/ASSP"
the ASSP directory is going to end up way deep into the directory  
structure.

>> Also, the errors I am seeing, sometimes they go away if I issue an  
>> uninstall, sometimes it seems more erratic.  At the paste url http://pastebin.com/m61fea40e 
>>  look at lines 96 and beyond, that is what I am trying to learn  
>> what they are all about.
>
> Before it runs the destroot phase, MacPorts creates various empty  
> directories for you in the destroot.

As a convenience? Why?  man pages and such, I would figure that is my  
job to make those, not macports?  What happens to all these  
directories when I install?  If I do not explicitly install them, they  
just go away with the rest of the cleanup procedure when the  
installation is done?

[...]

>> A good example is fs-traverse, which I think is just awesome, and  
>> in looking over other ports, trying to learn, there are clear cases  
>> where it would be a better choice to use than some of the for each  
>> loops people are doing in tcl.  I do not think fs-traverse is even  
>> mentioned on the docs.
>
> The Guide is still relatively new; it could still use a lot of work.  
> Please file tickets in the guide component / website & documentation  
> milestone about anything that needs to be added or changed. For  
> example, filing a ticket to get fs-traverse documented would be good.

Ok, I can do that, that is actually easy.  It puts more burden on the  
core ports devs to deal with docs, would it be beneficial at all to  
write copy along with the ticket, or am I wasting my time as there is  
some other internal procedure to get docs updated?

>>>> Thanks, once this works, I will work on the destroot and making  
>>>> sure it
>>>> does not nuke config and bayes database and other files, that  
>>>> should leave
>>>> me with figuring out what perl modules need ports.
>>>
>>> Note that during development of a port, it's best to initially run  
>>> through
>>> the destroot phase, and if at all possible, as a user who can't  
>>> write to the
>>> MacPorts install location.  Eg,
>>
>> If that user can not write to the /opt/local, what would this  
>> accomplish, aside from erroring out on a permission error?
>
> That's the point. Your port should not touch anything ${prefix}  
> directly, until MacPorts copies stuff there for you during  
> activation phase (or install phase, if in direct mode). During  
> destroot phase, it should only write into ${destroot}. By running  
> with a user that does not have permission to write into ${prefix},  
> you will immediately see, via a permission error, if the port is  
> writing to the wrong place during destroot phase.

Ah ha, understood, thanks, I will start to add this to my testing  
procedure.

>> Is there a list of all port commands, in short form, that I can use  
>> as a references?  Things like `port dir MacPorts` are tremendously  
>> useful, but hard to remember and learn about.
>
> Type "man port"

Geez, sometimes I can not see the forest for the trees, I do not know  
why I am disassociating the port command from any other tail, cat,  
more, ls, style command.  Thanks.

--
Scott