Bug 907027

Hm, that file is actually part of boost-devel already, as mentioned on http://rapidxml.sourceforge.net.

It could be considered a bundle there. I'd suggest to discuss that with the boost maintainers, in case you haven't already.

Thnaks for letting me know, will talk to them.

This indeed does look like bundling.  RapidXML is not a part of Boost API, it seems to be an implementation detail, much like e.g. ICU is.  I'll look into what the motivation was for doing it this way, and whether decoupling the two would be reasonable.

This doesn't install the library, just the headers?

It is implemented in headers (silly).

Ah, the completely empty main package confused me.  Please at least make that package depend on the -devel package.  Packages in the repo that do absolutely nothing aren't very nice.

It seems to me this is effectively a static library (albeit one that is compiled every time it's included).  You'd want to track it in the same way for all the same reasons (e.g. if a security flaw is found in it you'd want to rebuild everything that uses it).

So please follow the guidelines for static libraries:
http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

(Basically, just add "Provides: rapidxml-static = %{version}-%{release}" to -devel.)

(In reply to comment #6)
> Ah, the completely empty main package confused me.  Please at least make
> that package depend on the -devel package.  Packages in the repo that do
> absolutely nothing aren't very nice.
There is no empty "main" package produced, only -devel.

> (Basically, just add "Provides: rapidxml-static = %{version}-%{release}" to
> -devel.)
Done.

Spec URL: https://raw.github.com/hroncok/SPECS/master/rapidxml.spec
SRPM URL: https://github.com/downloads/hroncok/SPECS/rapidxml-1.13-2.fc18.src.rpm

Peter, how you see the (de)bundling issue now? Any news?

Package APPROVED

> Peter, how you see the (de)bundling issue now? Any news?

I haven't had time to look into it yet.

Anyway, this package should not interact or conflicts with boost-devel:

$ rpm -q -l boost-devel | grep rapidxml
/usr/include/boost/property_tree/detail/rapidxml.hpp
/usr/include/boost/property_tree/detail/xml_parser_read_rapidxml.hpp
$ rpm -q -l rapidxml-devel
/usr/include/rapidxml.h
/usr/include/rapidxml_iterators.h
/usr/include/rapidxml_print.h
/usr/include/rapidxml_utils.h
/usr/share/doc/rapidxml-devel-1.13
/usr/share/doc/rapidxml-devel-1.13/license.txt
/usr/share/doc/rapidxml-devel-1.13/manual.html

New Package SCM Request
=======================
Package Name: rapidxml
Short Description: Fast XML parser
Owners: churchyard
Branches: f17 f18 f19

Git done (by process-git-requests).

(In reply to comment #10)
> Anyway, this package should not interact or conflicts with boost-devel:

It wouldn't.  It's renamed and in a separate namespace.

It would still be worth it to unbundle it though.  I looked now, and it doesn't seem to be awfully different.  There's a bunch of renames (s/assert/BOOST_ASSERT/ must be like half of the changes) and a couple of what seems to be backport-worthy changes.  Some changes might be instances of RapidXML getting fixed and Boost not picking up that change.  It seems the header could be reworked into a little shim that just translates RapidXML names to what the rest of Boost expects.

rapidxml-1.13-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/rapidxml-1.13-2.fc19

rapidxml-1.13-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/rapidxml-1.13-2.fc18

rapidxml-1.13-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/rapidxml-1.13-2.fc17

rapidxml-1.13-2.fc19 has been pushed to the Fedora 19 testing repository.

rapidxml-1.13-2.fc19 has been pushed to the Fedora 19 stable repository.

rapidxml-1.13-2.fc17 has been pushed to the Fedora 17 stable repository.

rapidxml-1.13-2.fc18 has been pushed to the Fedora 18 stable repository.