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

Reply via email to