On Wed, Jan 21, 2026 at 11:35:21AM +0100, Miro Hrončok wrote:
> On 21. 01. 26 4:20, Gordon Messmer wrote:
> > On 2026-01-16 11:39 AM, Miro Hrončok wrote:
> > > > It is my opinion that offering versioned symbols to expat is so
> > > > simple that even a caveman could do it (insert insurance
> > > > commercial here), while refactoring Python's code (not to
> > > > mention every other application that uses the new symbols) is
> > > > not something I would ask package maintainers to do.
> > > 
> > > Are you willing to be that caveman? 🙂
> > 
> > 
> > I spoke to the developer of expat to answer some questions he had about
> > versioned symbols, and we're about 90% of the way to an acceptable PR:
> > 
> > https://github.com/libexpat/libexpat/pull/1134
> > 
> > This PR is more complex than I think will be typical because the
> > maintainer would like versioned symbols to be opt-in for now, and
> > because the project supports two different build systems, and because
> > the maintainer had some information available about symbol version
> > history, which I preserved.
>
> Thank you!
> 
> One thing that I'd like to get clarified: If this is released in the next
> expat version and we add the --enable-symvers configure flag, do we need to
> rebuild everything that links to libexpat, or not?

No rebuild needed. Apps pick up the new versioned symbol deps "as needed"
next time they're built.

Enabling symbol versions is fully backwards compatible. An existing
application linkage will be requiring the unversioned symbol, and that
*can* be satisfied by a versioned symbol.

The reverse, disabling symbol versions, is NOT compatible, and would
require a full rebuild of deps. If an application requires a versioned
symbol, that can not be satisfied by an unversioned symbol.

IOW, once sym versions are enabled, it is painful to get rid of them
again - it has the equivalent impact to an soname bump.



With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

-- 
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to