trunk and 10.3 support

[Ryan Schmidt]

On Mar 2, 2009, at 01:38, Jordan K. Hubbard wrote:

> On Mar 1, 2009, at 10:53 PM, Bryan Blackburn wrote:
>
>> The problem is that 10.3 doesn't support lchown() which means that  
>> currently
>> trunk fails to build there.  Using a HAVE_LCHOWN test, we could  
>> fall back to
>> using just chown() but then we're right back to the original  
>> problem but
>> just for 10.3.  Porting lchown() to 10.3 is not going to happen  
>> unless we
>> start shipping a custom kernel for those machines.
>
> You could also simply punt on the notion of link ownership for tiger

Panther, not Tiger.

> (call chown() for non-links, do nothing for links) since I seem to  
> recall that they inherited their ownership information from their  
> containing directory on 10.3 anyway - links have been somewhat less  
> "real" in prior releases than they are today.


I found this page:

http://www.jacek-dom.net/software/psync/readme.txt

It says:

"Note on Panther symlinks attributes: In older versions of BSD (and  
in OS X 10.2 and earlier) symbolic links did not have their own  
attributes (ownership and permissions) - they inherited attributes of  
objects they pointed to. In FreeBSD 5.1 (on which Panther is based in  
large part) symbolic links have their own attributes. However, Apple,  
while porting FreeBSD to Darwin, allowed symlinks to have its own  
attributes, but disabled all code that allowed to manipulate those  
attributes - the system calls that implement it (lchmod, lchown and  
lutimes) are commented out in source code (you can see for yourself:  
<http://www.opensource.apple.com/darwinsource/10.3/file_cmds-82/>).  
They did not remove it from documentation - so man pages for chmod,  
chown, chgrp and touch describe the new -h option that allows to  
modify symlink attributes, but it does not work. I am sure that they  
had a very good reason to do that :)."

I have not tested whether this information is still accurate. But  
even if it is, I don't think this is any reason to kill all hopes of  
running MacPorts 1.8.0 on Panther, especially since it would be no  
different than any previous version of MacPorts in regard to symlink  
ownership.

Also note that we have another feature in MacPorts already that does  
not work on Panther: the -E option to reinplace. Rather than cutting  
off Panther support entirely at that point, the solution that was  
implemented simply makes the -E option unavailable in reinplace on  
Panther. So any of the 67 ports that use that option won't work on  
Panther, but others will. Some of those ports probably don't even  
need to use the -E option; someone probably just copied it from  
another port and didn't know what it was for. In fact I would imagine  
any of them could be rewritten to not use the -E option if necessary.