I became aware through https://github.com/signalwire/freeswitch/pull/2768 : # xmlrpc-c-1.59.03/configure --help | grep expat --enable-libxml2-backend Use libxml2 instead of built-in expat ^^^^^^^^ I have reached out to upstream via e-mail. I should mention that the Gentoo package is marked "maintainer-needed". I'm open to suggestions about how to best address the issue in Gentoo and may be able to help.
Sounds like we should just drop USE=libxml2 there and make it mandatory (as if it was always on) on our end? If you foresee a possible resolution upstream, it's fine if we package.use.force libxml2 on for now.
What I like about package.use.force is how fast and simple it is and how it would be hard to revert by accident, e.g. because it comes with a line of dedicated documentation. Maybe it makes for a great first step? Do you see any downsides? Or we could turn the arguments to econf into a Bash array "args" where we can then add an inline comment about why libxml2 is used unconditionally that would be hard to miss. I'm happy to follow your preference. Which do you prefer? PS: An upstream solution is hopefully coming. I am sensing that full removal of (bundled) Expat in favor of (system) libxml2 is not unlikely in this case.
(In reply to Sebastian Pipping from comment #2) > What I like about package.use.force is how fast and simple it is > and how it would be hard to revert by accident, e.g. because it comes > with a line of dedicated documentation. > > Maybe it makes for a great first step? Do you see any downsides? > I think the only downside is that it becomes techdebt in the ebuild to support USE=-libxml2 if it never gets resolved. But it should be OK if we keep this bug open to remind us. > Or we could turn the arguments to econf into a Bash array "args" > where we can then add an inline comment about why libxml2 is used > unconditionally that would be hard to miss. > > I'm happy to follow your preference. Which do you prefer? > Let's do the quick p.use.force, I agree with you. > PS: An upstream solution is hopefully coming. I am sensing that > full removal of (bundled) Expat in favor of (system) libxml2 is > not unlikely in this case. Excellent!
(In reply to Sam James from comment #3) > Let's do the quick p.use.force, I agree with you. Is adding to both… ./releases/17.0/package.use.force ./releases/23.0/package.use.force …the right edit?
(In reply to Sebastian Pipping from comment #4) base/package.use.force (only) is the better place
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bc9b6db63e38e56b295e71ece3a3128a75822d03 commit bc9b6db63e38e56b295e71ece3a3128a75822d03 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2025-03-26 23:41:52 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2025-03-26 23:41:52 +0000 profiles/base: Block dev-libs/xmlrpc-c[-libxml2] Bug: https://bugs.gentoo.org/952113 Signed-off-by: Sebastian Pipping <sping@gentoo.org> profiles/base/package.use.force | 5 +++++ 1 file changed, 5 insertions(+)
(In reply to Sam James from comment #5) > base/package.use.force (only) is the better place Thanks!
Quick update that deleting lib/expat/ in the ebuild would effectively kill all tests. common.mk seems to bring it in unconditionally: # grep -C1 lib/expat [..]/work/xmlrpc-c-1.59.03/common.mk | tail -n 7 $(LIBXMLRPC_XMLPARSE) $(LIBXMLRPC_XMLPARSE_A) : FORCE $(MAKE) -C $(dir $@) -f $(SRCDIR)/lib/expat/xmlparse/Makefile \ $(notdir $@) -- $(LIBXMLRPC_XMLTOK) $(LIBXMLRPC_XMLTOK_A) : FORCE $(MAKE) -C $(dir $@) -f $(SRCDIR)/lib/expat/xmltok/Makefile \ $(notdir $@) I'll wait for upstream's recent >=1.65.00 work in Subversion (https://sourceforge.net/p/xmlrpc-c/code/3293/tree/release_number/1.65.00/) to become available as release tarballs before having a closer look again.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=61b6130343a41b49da1ffe7376ab5d2077a37411 commit 61b6130343a41b49da1ffe7376ab5d2077a37411 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2025-04-06 01:54:52 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2025-04-06 02:13:19 +0000 dev-libs/xmlrpc-c: Unbundle dev-libs/expat Bug: https://bugs.gentoo.org/952113 Signed-off-by: Sebastian Pipping <sping@gentoo.org> .../files/xmlrpc-c-1.59.03-use-system-expat.patch | 229 +++++++++++++++++++++ dev-libs/xmlrpc-c/xmlrpc-c-1.59.03-r2.ebuild | 90 ++++++++ 2 files changed, 319 insertions(+)
Hi! I have added 1.59.03-r2 just now that deletes the bundled lib/expat/ altogether and uses system libexpat in its place. From here, I envision this 3-step way forward (in this order): 1. Loosen the package.use.force entry to: <=dev-libs/xmlrpc-c-xmlrpc-c-1.59.03-r1 libxml2 2. Stabilize dev-libs/xmlrpc-c-xmlrpc-c-1.59.03-r2 (via a dedicated bug) 3. Drop the package.use.force entry and all four <=1.59.03-r1 ebuilds at the same time. What do you think? Best, Sebastian
Update: I realize now that with the other open xmlrpc-c bugs and e.g. GCC 15 support broken, before further version bumps stabilization may be hard to impossible. So then only step (1) for now — loosening the package.use.force entry to "<=dev-libs/xmlrpc-c-xmlrpc-c-1.59.03-r1 libxml2"? Any objections?
