Spec URL: http://people.atrpms.net/~hdegoede/tinyxml.spec SRPM URL: http://people.atrpms.net/~hdegoede/tinyxml-2.5.3-1.fc9.src.rpm Description: TinyXML is a simple, small, C++ XML parser that can be easily integrating into other programs. Have you ever found yourself writing a text file parser every time you needed to save human readable data or serialize objects? TinyXML solves the text I/O file once and for all. (Or, as a friend said, ends the Just Another Text File Parser problem.)
Since there is no library compiled in the upstream Makefile, it seems to me that adding a soname is dangerous if upstream decides to do a shared library later with the same soname. Therefore, doing only a static library would seems to me to be less dangerous.
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. 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.
(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.
I really do not want to use lib%{name}.so.0.fedora, thats just too ugly for words. Upstream's intention is for this to be included with other sources, they do not even offer a Makefile to build a .a, so the chances of there ever coming an official .so are small. Also most likely I'll change the soname to lib%{name}-%{version}.so with the first new upstream version, as I expect them to not care about ABI's and hapily break it each release (its really easy to cause ABI breakage with c++). But I'm using lib%{name}.so.0 for now in the hope that they will pleasantly surprise me. If I stick with a lib%{name}.so.x versioning scheme and upstream ever decides to start shipping a .so lets deal with that then.
(In reply to comment #4) > I really do not want to use lib%{name}.so.0.fedora, thats just too ugly for > words. I don't care about the precise soname, as long as it isn't something upstream is likely to use in the future. > Upstream's intention is for this to be included with other sources, they > do not even offer a Makefile to build a .a, so the chances of there ever > coming an official .so are small. They may change their mind. > Also most likely I'll change the soname to lib%{name}-%{version}.so with the > first new upstream version, as I expect them to not care about ABI's and > hapily break it each release (its really easy to cause ABI breakage with > c++). But I'm using lib%{name}.so.0 for now in the hope that they will > pleasantly surprise me. Using the lib%{name}-%{version}.so scheme would seem better to me since hopefully upstream won't do that. In my opinion it is better to anticipate rather than deal with later complexity.
(In reply to comment #5) > > Upstream's intention is for this to be included with other sources, they > > do not even offer a Makefile to build a .a, so the chances of there ever > > coming an official .so are small. > > They may change their mind. > Yes they may, but I cannot and forsee and thus cannot anticipate every possible future development, and as things are today there is no indication they will ever add a buildsystem, let alone building a .so to their non existant buildsystem. > > Also most likely I'll change the soname to lib%{name}-%{version}.so with the > > first new upstream version, as I expect them to not care about ABI's and > > hapily break it each release (its really easy to cause ABI breakage with > > c++). But I'm using lib%{name}.so.0 for now in the hope that they will > > pleasantly surprise me. > > Using the lib%{name}-%{version}.so scheme would seem better to me > since hopefully upstream won't do that. > Yes, but if they do bugfix releases which do not break ABI this will cause unnecessary soname changes, so I will adopt this scheme in the future if they often break ABI, but I do not want to start out with this scheme.
I am contacting upstream, hopefully they will clarify their future position.
I can put you in CC with upstream if you like.
(In reply to comment #7) > I am contacting upstream, hopefully they will clarify their > future position. Ok. (In reply to comment #8) > I can put you in CC with upstream if you like. Yes please.
Upstream responded and I have cced you on my response to upstream such that you can say whatever you want. Upstream response was: That's great to see it going into Fedora! For better or worse, TinyXML is delivered as a set of C++ and .h files. It has a makefile, and an XCode project, and a VC project...but they are really only for the demo. None of them are intended to build a "shipping" library. There certainly isn't a policy in place regarding SO naming, and we have no plans to start one. If you guys have a policy, I'd be happy to use that in the (unlikely) case we change our minds. So basically you are free to use any soname naming convention you like. Please tell whether your current spec satisfies you (given upstream response) or post a new srpm.
I'm happy with the specfile as is, thanks for clarifying things with upstream.
The tinyxml.h timestamp isn't kept, one way to achieve that would be to do something like %patch0 -p1 -b .stl touch -r tinyxml.h.stl tinyxml.h Otherwise on multilib installs rpm -V will show spurious differences. If I recall well, it is advised to use $RPM_OPT_FLAGS during linking (for the arch -m* options), maybe you could consider doing that? Also in general the library name contains the version, like g++ -shared -o lib%{name}.so.%{version} -Wl,-soname,lib%{name}.so.0 *.cpp.o And then you can use ldconfig to do the first link, like install -m 755 lib%{name}.so.%{version} $RPM_BUILD_ROOT%{_libdir} /sbin/ldconfig -n $RPM_BUILD_ROOT%{_libdir}/ ln -s lib%{name}.so.0 $RPM_BUILD_ROOT%{_libdir}/lib%{name}.so I don't have any other comment.
(In reply to comment #12) > The tinyxml.h timestamp isn't kept, one way to achieve that would be > to do something like > > %patch0 -p1 -b .stl > touch -r tinyxml.h.stl tinyxml.h > > Otherwise on multilib installs rpm -V will show spurious differences. > > > If I recall well, it is advised to use $RPM_OPT_FLAGS during linking > (for the arch -m* options), maybe you could consider doing that? > > > Also in general the library name contains the version, like > g++ -shared -o lib%{name}.so.%{version} -Wl,-soname,lib%{name}.so.0 *.cpp.o > And then you can use ldconfig to do the first link, like > install -m 755 lib%{name}.so.%{version} $RPM_BUILD_ROOT%{_libdir} > /sbin/ldconfig -n $RPM_BUILD_ROOT%{_libdir}/ > ln -s lib%{name}.so.0 $RPM_BUILD_ROOT%{_libdir}/lib%{name}.so > > > I don't have any other comment. Sorry for the long silence, I got distracted adding mms seeking support to gstreamer, see: http://hansdegoede.livejournal.com All above comments are fixed now: Spec URL: http://people.atrpms.net/~hdegoede/tinyxml.spec SRPM URL: http://people.atrpms.net/~hdegoede/tinyxml-2.5.3-2.fc9.src.rpm
* rpmlint is silent * follow packaging guidelines * sane provides Provides: libtinyxml.so.0 * match upstream 84b605a31628e7f1a6694d47bf5999cc tinyxml_2_5_3.tar.gz * lib correctly packaged * %files section right Only one thing that is not right, the source timestamp is not kept: -rw-rw-r-- 1 dumas dumas 196129 nov 30 17:44 ../SOURCES/tinyxml_2_5_3.tar.gz -rw-rw-r-- 1 dumas dumas 196129 mai 7 2007 tinyxml_2_5_3.tar.gz Fix that and it is approved (since this cannot be fixed post-import).
Ok, I've replaced: SRPM URL: http://people.atrpms.net/~hdegoede/tinyxml-2.5.3-2.fc9.src.rpm With a version with the correct timestamp.
APPROVED
Thanks for the review! New Package CVS Request ======================= Package Name: tinyxml Short Description: A simple, small, C++ XML parser Owners: jwrdegoede Branches: F-7 F-8 devel InitialCC: <empty> Cvsextras Commits: yes
cvs done.
Imported and build, closing.
This is request for EL-6 branch. Once cvs is done I will close it again. Thanks, New Package CVS Request ======================= Package Name: tinyxml Short Description: A simple, small, C++ XML parser Owners: rakesh Branches: EL-6 InitialCC:
CVS done.
This is request of EL-5 branch. Changing status to ASSIGNED. Will CLOSE once request is granted. New Package CVS Request ======================= Package Name: tinyxml Short Description: A simple, small, C++ XML parser Owners: rakesh Branches: EL-5 InitialCC:
tinyxml is already in the distribution; we cannot process a new package request for it.
(In reply to comment #23) > tinyxml is already in the distribution; we cannot process a new package request > for it. My mistake This is a new branch request for EL 5 New Branch Request ======================= Package Name: tinyxml Short Description: A simple, small, C++ XML parser Owners: rakesh Branches: EL-5 InitialCC:
Still no valid request to process. As these are processed by a script, please follow http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages exactly.
Package Change Request ====================== Package Name: tinyxml New Branches: el5 Owners: rakesh Changing status back to what it was. Thanks for pointer.
Git done (by process-git-requests).
tinyxml-2.6.1-2.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/tinyxml-2.6.1-2.el5
tinyxml-2.6.1-2.el5 has been pushed to the Fedora EPEL 5 stable repository.
Package Change Request ====================== Package Name: tinyxml New Branches: el4 Owners: rakesh
Rakesh: please build tinyxml on el4 ASAP as per comment #30 so I can update cppcheck.
Rakesh, ping?
(In reply to comment #33) > Rakesh, ping? I have been busy lately, will do it before this Sunday evening. In case I fail to will request someone else to import it.
EPEL-4 build submitted as https://admin.fedoraproject.org/updates/tinyxml-2.6.1-2.el4