Thanks for the correction - I have a hard time keeping the various
releases straight since they all seem to kind of blend into one
another for some reason. :-)
I don't think the question is "whether to exclude Panther" (though at
almost 6 years old, one wonders how long users might expect open
source projects to support it), but rather how much forward progress
should be held hostage to releases like Panther. I believe the
original question regarded the implementation of one of the GSoC
projects and what to do in the case of an old release, for which my
suggestion was simply "punt" given the low reward-to-effort ratio.
- Jordan
On Mar 2, 2009, at 12:15 AM, Ryan Schmidt wrote:
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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
