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