Re: gsasl 2 libgsasl{18,-common,-devel,-doc}

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2022-07-18 05:43, Marco Atzeri wrote:
> 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

Hi folks, [Please Reply All as ISP blocking Cygwin mail]

It looks as if gsasl 2 is ABI 18 compatible with gsasl 1.10, so I am 
looking to release 2.2 as a continuation of the existing versions, and 
that is consistent with FreeBSD and Debian, where the developer appears 
to be among the package maintainers.

One issue is that autoreconfig replaces the package provided 
gtk-doc.make with one from /usr/share/gtk-doc/data/gtk-doc*.make and 
they (all) need patched to build PDFs with DESTDIR builds.

I handled this with local patches, added a src_patch_apply_hook to apply 
these for scallywag builds, and submitted patches upstream to the gsasl 
list and gtk-doc repo.

The current orphaned gtk-doc cygport build seems to work automagically 
from the upstream tar(.xz) included in the source package, and I am too 
ignorant of Gnome, GTK, dblatex, TeX, etc., that I am uncomfortable 
adopting gtk-doc, as I have enough backlogged package updates.

Suggestions for doing a non-maintainer update?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]