trunk and 10.3 support

[Jeremy Huddleston]

Isn't Panther *already* not "officially" supported anymore?

http://www.macports.org says:
"""
We provide a single software tree that attempts to track the latest  
release of every software title (port) we distribute, without  
splitting them into “stable” Vs. “unstable” branches, targetting  
mainly the current Mac OS X release (10.5, A.K.A Leopard) and the  
immediately previous one (10.4, A.K.A. Tiger).
"""

To me, that implies that we try not to break older releases, but we  
won't bend over backwards to support them either.

Add the HAVE_LCHOWN bits to configure.ac and let Panther users deal  
with the issue.  They have thus far.

--Jeremy


On Mar 2, 2009, at 00:34, Jordan K. Hubbard wrote:

> 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
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev