On 18.07.2022 07:10, Brian Inglis wrote:
I'd like to adopt orphaned package gsasl as new versions have been released.

     https://cygwin.com/packages/summary/gsasl-src.html


all yours

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gsasl.git

I've rebuilt current 1.8 and upgraded releases 1.8.1, 1.10, 2.0, and
2.0.1 for x86/i686 and x86_64 without any issues.
The 2.0.1 build was run in GitHub Actions CI using the gsasl repo
playground branch; see:

     https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=gsasl

and scallywag logs are at:

     https://github.com/cygwin/scallywag/actions/runs/2682310926

I'd like to release 1.10 which is ABI compatible, as a test release with
libcurl4 depending on it (also mine), a lot of libraries depend on that,
and a lot of packages depend on those; try:

     $ cygcheck-dep -qSN libgsasl7 | less

Release 2.0 jumps to libgsasl18, so that should probably be released as
gsasl2/libgsasl2-{common,-devel,-doc}, and libcurl4 built and test released with that?

Should the new library stay as libgsasl18 or be named libgsasl2_18?

I would follow the name of the library.
If it is just cyggsasl-18.dll use libgsasl18

How to rebuild libcurl4 with libgsasl2-devel using libgsasl{2_}18?

I suggest to avoid collision between version 1 and 2.
possibly moving away the old version and leaving in the usual place the last one

/usr/include/*.h -> /usr/include/gsasl1/*.h
usr/lib/libgsasl.dll.a usr/lib/gsasl1/libgsasl.dll.a


Regards
Marco

Reply via email to