[Bug 407571] Review Request: tinyxml - A simple, small, C++ XML parser

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: tinyxml - A simple, small, C++ XML parser


https://bugzilla.redhat.com/show_bug.cgi?id=407571





------- Additional Comments From pertusus at free.fr  2007-12-02 05:33 EST -------
(In reply to comment #2)
> I don't understand, first you ask me to package this seperately (which I found
> reasonable), and now you ask for a static lib, which is against the guidelines
> and which would negate all advantages of having this in a seperate package.

Not necessarily. Having a separate library is interesting even if it is
static. As for the static libraries, they are not against the guidelines
when upstream only provides static libraries. Here upstream even proposes
to ship in source source files, which is even worse. 

The state of affair with static libs is that maintainers of packages that
depend on static libs have to be in initialCC, to be aware of what 
is happening with the static lib in order to know when packages need to
be rebuilt.

Still you are right, static libs are discouraged because indeed it is
less convenient than shared libs because maintainers have to follow the
(big) bugs of all the static libraries they depend on.

> Don't worry about ABI breakage, I'm quite experienced in packaging things as .so
> where upstream only wants to support a .a, I will do  a diff of the public
> headers each new upstream release and bump the .so as needed.

I have no worry about your capacity to manage properly a shared library.
The issue is really with colliding sonames corresponding with incompatible
ABI. For example in fedora you have libtinyxml.so.3, then upstream begins
doing shared libs, and soon releases libtinyxml.so.1. Of course you can
follow a parallel path and use libtinyxml.so.4 in fedora since 
libtinyxml.so.1 was associated with a previous version, but it is not
right. You can also do versioned requires and obsoletes to ensure proper 
upgrade even though the automatically generated soname dependencies
are wrong, but it is complicated and messy.

I see a possibility though, it would be to have a soname special for fedora,
instead of lib%{name}.so.0, use something along lib%{name}.so.0.fedora
or similar. That would be acceptable. But plainly using lib%{name}.so.0
for the soname is asking for future troubles in my opinion.

Of course there are exceptions, for example for libraries upstream has 
said it would never ever release shared libraries or libraries that
have dead upstream and that are not likely to revive with the same
soname.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.