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
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
