Re: [ITP] rsync 3.2.6

[Chad Dougherty <crd@acm.org>]

On 2022-10-09 10:23, Jon Turney wrote:
 > Thanks for looking into updating this.  I'd like to give the existing
 > maintainer first refusal, though.
 >

Absolutely.  It's totally OK with me if Jari would rather still maintain 
this.  I just figured I'd try my hand at the process in the meantime, 
particularly since it was using the old build method.

> Comments on this cygport:
> 
>> REQUIRES="libiconv2 libssl1.1 libxxhash0 libzstd1 liblz4_1"
> 
> You don't (and in fact, shouldn't, because you then need to remember to 
> manually update them e.g. when soversions change) list here packages 
> that cygport can automatically detect as dependencies.
> 

I see, thanks.  Fixed in my working repo here:
https://github.com/crd477/cygports/tree/main/rsync

>> # Enable this function for releases that work without autoreconf
>> src_compile()
> 
> You should only override the default src_compile if it doesn't work.
> 
> The fact that autoreconf isn't apparently necessary, doesn't mean it 
> should be omitted, since that means that future fixes to the 
> autoconfiguration machinery aren't automatically incorporated into the 
> package, but will only appear when upstream updates the autotools used 
> to generate the distributed autoconfiguration files.
> 

I see.

I tried but the default src_compile() didn't work.  According to the 
INSTALL file, the autoconf should only be done on a git checkout, not 
the release tarball.

The specific comment in the cygport file was actually a holdover from 
one I was using as an example so I've clarified it.

> (I think this topic is touched upon in the cygport reference manual in 
> the section on cygautoreconf, but perhaps that could be clearer)
> 

I actually hadn't read that section yet.  The warning in the reference 
manual is pretty clear now that I see it though.  Might it be a good 
idea to issue a warning diagnostic at src_compile time if cygautoreconf 
is skipped but it looks like the source code should be able to handle it?

> Comparing the contents of the packages this produced with the current 
> package, there are various /usr/share/doc/rsync/*.{html,txt} files which 
> are no longer packaged.  Is this intentional?
> 

It was not really intentional.  The only reason they were left out is 
that they weren't part of the default install rule.
I've also addressed this in the working repo mentioned above.

Thanks for taking the time to review this.  I really appreciate it. 
rsync is an important tool so I'm a little anxious about screwing it up 
for some other user of the package.

-- 
     -Chad