[Bug 262940] textproc/libxml2 and textproc/py-libxml2: Revert back to GNU Autotools due to some curl dependencies?

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 30 Mar 2022 15:26:12 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262940

            Bug ID: 262940
           Summary: textproc/libxml2 and textproc/py-libxml2: Revert back
                    to GNU Autotools due to some curl dependencies?
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: desktop@FreeBSD.org
          Reporter: diizzy@FreeBSD.org
                CC: jbeich@FreeBSD.org, mandree@FreeBSD.org,
                    sunpoet@FreeBSD.org, tcberner@freebsd.org,
                    tijl@FreeBSD.org, yasu@freebsd.org
             Flags: maintainer-feedback?(desktop@FreeBSD.org)

Created attachment 232821
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232821&action=edit
Patch for libxml2 and py-libxml2

Unfortunately the change to CMake causes circular dependency for some non
default options in (lib)curl that I missed during testing.

Examples :
textproc/libxslt depends on --> textproc/libxml2
textproc/libxml2 depends on --> devel/cmake (currently)
devel/cmake depends on --> ftp/curl

Circular issues I found looking at it closer:
(lib)psl option in curl depends on libxslt
gnutls option in curl depends on (lib)unbound via DANE option (non default
option), (lib)unbound depends on protobuf-c via DNSTRAP option (non default
option) which depends on cmake
gnutls also depends on trousers via TPM option (default), trousers depends on
tpm-emulator which depends on cmake

Based on the information above I used repology to look at others distros and it
looks like this:
Alpine Linux --> no libpsl (hardset), openssl (no option to change crypto lib)
Arch Linux --> libpsl (by default), openssl (no option to change crypto lib)
Debian --> libpsl (by default), gnutls flavour (offers gnutls with dane
support, no tpm support (hardset)), builds unbound with protobuf support
Fedora --> libpsl (full package only), openssl (no option to change crypto lib)
Gentoo --> no libpsl (hardset), gnutls flavour (offers gnutls with dane
support, no tpm support (hardset)), builds unbound with protobuf support
OpenBSD --> no libpsl (hardset), open/libretls (no option to change crypto lib)
OpenSUSE --> libpsl (by default), openssl and nss flavours

One option would be to at least for now disable those two conflicting options
if its acceptable to limit some functionality (which is up to the maintainer to
decide in the end imo). 

While it might not add much to the decision making upstream have expressed some
struggles with Autotools such as here
https://gitlab.gnome.org/GNOME/libxslt/-/issues/36#note_765202 although wants
to keep it as preferred option for Unix
https://gitlab.gnome.org/GNOME/libxml2/-/issues/360 . However upstream is also
willing to accept patches to improve both build systems (I have submitted few
simple ones).

Meanwhile I've tried to clean up the port to the best of my ability but I'd
appreciate a review or two if we device to go back.

Sorry but the issues caused by this change but as they say, you learn from your
mistakes.

Compile tested on FreeBSD 13.0-STABLE #2 stable/13-n248607-93a95ebbf7c (amd64)
(make, make check-plist)
Poudriere testport OK 12.2-RELEASE (amd64)
Poudriere testport OK 13.0-RELEASE (i386)
This also includes py-libxml2

Tested ports (consumers):
devel/glib20
devel/libnotify
dns/libpsl
graphics/wayland
irc/bitlbee
mail/neomutt
security/libsecret
security/p11-kit
textproc/xmlto
audio/icecast
devel/tclxml
net/yaz
devel/libaravis

-- 
You are receiving this mail because:
You are the assignee for the bug.