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@xxxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review