I briefly looked at the rsync as provided by macosxlabs.org.   In my 
opinion, the key criteria for replacing the rsync package as distributed 
by Fink are two fold:

Compatibility

        It appears that rsync+HFS (for lack of a better moniker) maintains 
compatibility with the non-extended rsync.  As well, it doesn't appear to 
be a problem to build this version of rsync.   And it doesn't appear to 
break when talking within a non-extended version of rsync.

Speed of Updates

        It would be rather unfortunate if we were to move to a 'nonstandard' 
version of rsync only to find that the version included in Fink lags 
behind the 'real' release by several versions for a good part of the time.
    Given rsync's role in the system and that it is often invoked in a 
privileged context, security issues are very real and it is relatively 
critical that we continue to be able to ship a new version of the package 
in a timely fashion.

        As such, it would be much more attractive if the HFS extensions were 
included in the rsync development trunk.  However, it also appears that 
rsync+hfs has been kept in sync with rsync itself (though, it has been a 
while since rsync itself has been updated, it appears).

        Given all that, I have no particular problem putting together an 
rsync+hfs (rsyncx?) package for Fink.   Given the potential for version 
lag and the untested compatibility (in the context of Fink), I would 
recommend both a separate package and that rsyncx live in unstable/ for a 
while.

(Of course, those with good memories will remember that I haven't exactly 
been prompt in tracking rsync updates...  I'm not at all territorial about 
the packages that I maintain -- if others catch updates to the core and 
want to contribute updated packages to fink, feel free.  Or ping me and I'
ll update it...)

b.bum


On Wednesday, July 10, 2002, at 06:17 AM, Stefan Berreth wrote:

> Tue, 9 Jul 2002 22:01:26 +0200
>
>> At 13:57 Uhr +0200 09.07.2002, Stefan Berreth wrote:
>
> [...]
>
>>>
>>> but: can anybody explain to me why the rsync version installed by fink 
>>> is
>>> not the HFS+ filesystem enhanced version of rsync? (see <http://
>>> www.macosxlabs.org/rsyncx/rsyncx.html>)
>>>
>>
>> [...]
>>
>>> - is there a good reason why fink does not install the HFS+ enhanced
>>> evrsion of a tool when available?
>>
>> Because this is the rsync package. Nothing prevents you from making a
>> "rsyncx" package, though, if it is a command line app. If it is a Mac
>> OS X GUI app (Cocoa/Carbon), it shouldn't be package via Fink.
>
> hmm, the actual commandline tool is the 'original' rsync with added
> support for HFS+ if both sides have a HFS+ supporting rsync version. So
> it may well be the default version on OSX. I actually don't understand
> why apple ships with the non-HFS+ suporting version.
>
> And yes, you are right, there is OS X GUI app shipping with the rsyncX
> archive at the URL above that operates on top of the rsync commandline
> tool. The GUI app should of course not be part of a fink tool 
> installation.
>
>
>>
>> In any case the original rsync package will stay, too, for people who
>> have to use the original version for various reasons.
>>
>
> Whereas i oftern understand the need for this position, I fail to see it
> in this particular case.
>
> The rsync version with HFS+ support is the _identical_ code for non-HFS+
> situations. The original package is simply inapropriate for the
> underlying filesystem on OSX. I don't see why one would prefer using a
> rsync version that has the identical codepath of the HFS+ supporting
> version but breaks data when it comes across HFS+ specific file features.
>

.....



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf
_______________________________________________
Fink-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-users

Reply via email to