This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 407571 - Review Request: tinyxml - A simple, small, C++ XML parser
Review Request: tinyxml - A simple, small, C++ XML parser
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Patrice Dumas
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 405171
  Show dependency treegraph
 
Reported: 2007-12-01 17:40 EST by Hans de Goede
Modified: 2011-08-01 17:23 EDT (History)
5 users (show)

See Also:
Fixed In Version: tinyxml-2.6.1-2.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-01 17:23:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pertusus: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2007-12-01 17:40:28 EST
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.)
Comment 1 Patrice Dumas 2007-12-01 19:11:22 EST
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.
Comment 2 Hans de Goede 2007-12-02 04:35:34 EST
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.
Comment 3 Patrice Dumas 2007-12-02 05:33:24 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.
Comment 4 Hans de Goede 2007-12-02 13:54:01 EST
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.
Comment 5 Patrice Dumas 2007-12-02 14:59:45 EST
(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.
Comment 6 Hans de Goede 2007-12-02 16:08:49 EST
(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.
Comment 7 Patrice Dumas 2007-12-03 04:55:29 EST
I am contacting upstream, hopefully they will clarify their 
future position.
Comment 8 Patrice Dumas 2007-12-03 05:08:08 EST
I can put you in CC with upstream if you like.
Comment 9 Hans de Goede 2007-12-03 06:00:43 EST
(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.
Comment 10 Patrice Dumas 2007-12-04 05:34:12 EST
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.
Comment 11 Hans de Goede 2007-12-04 10:15:19 EST
I'm happy with the specfile as is, thanks for clarifying things with upstream.
Comment 12 Patrice Dumas 2007-12-04 13:14:00 EST
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.
Comment 13 Hans de Goede 2007-12-14 14:34:04 EST
(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
Comment 14 Patrice Dumas 2007-12-14 15:04:44 EST
* 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).
Comment 15 Hans de Goede 2007-12-15 04:33:09 EST
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.
Comment 16 Patrice Dumas 2007-12-16 12:15:51 EST
APPROVED
Comment 17 Hans de Goede 2007-12-16 13:56:53 EST
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
Comment 18 Kevin Fenzi 2007-12-16 17:04:23 EST
cvs done.
Comment 19 Hans de Goede 2007-12-17 09:22:11 EST
Imported and build, closing.
Comment 20 Rakesh Pandit 2010-06-22 11:30:10 EDT
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:
Comment 21 Kevin Fenzi 2010-06-22 21:38:08 EDT
CVS done.
Comment 22 Rakesh Pandit 2011-03-04 00:43:11 EST
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:
Comment 23 Jason Tibbitts 2011-03-04 08:05:48 EST
tinyxml is already in the distribution; we cannot process a new package request
for it.
Comment 24 Rakesh Pandit 2011-03-04 09:31:30 EST
(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:
Comment 25 Jason Tibbitts 2011-03-04 13:47:54 EST
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.
Comment 26 Rakesh Pandit 2011-03-04 14:01:35 EST
Package Change Request
======================
Package Name: tinyxml
New Branches: el5
Owners: rakesh

Changing status back to what it was. Thanks for pointer.
Comment 27 Jason Tibbitts 2011-03-04 16:19:41 EST
Git done (by process-git-requests).
Comment 28 Fedora Update System 2011-04-06 14:48:03 EDT
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
Comment 29 Fedora Update System 2011-04-21 15:55:04 EDT
tinyxml-2.6.1-2.el5 has been pushed to the Fedora EPEL 5 stable repository.
Comment 30 Rakesh Pandit 2011-05-24 05:50:47 EDT
Package Change Request
======================
Package Name: tinyxml
New Branches: el4
Owners: rakesh
Comment 31 Jason Tibbitts 2011-05-24 10:44:09 EDT
Git done (by process-git-requests).
Comment 32 Susi Lehtola 2011-06-13 11:45:17 EDT
Rakesh: please build tinyxml on el4 ASAP as per comment #30 so I can update cppcheck.
Comment 33 Dan Horák 2011-07-18 12:57:59 EDT
Rakesh, ping?
Comment 34 Rakesh Pandit 2011-07-18 18:03:50 EDT
(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.
Comment 35 Dan Horák 2011-08-01 17:23:50 EDT
EPEL-4 build submitted as https://admin.fedoraproject.org/updates/tinyxml-2.6.1-2.el4

Note You need to log in before you can comment on or make changes to this bug.