pmachata at redhat.com
Fri Feb 4 22:38:46 UTC 2011
04.02.2011 14:59, Rex Dieter wrote:
> Petr Machata wrote:
>> beta of boost-1.46.0 was released recently and packaged yesterday. It's
>> now in the git, and a scratch build was done. This is in preparation
>> for final release that should be out on 7th, just before the feature
>> freeze. Providing boost-1.46.0 is one of features of F15.
>> I'm in the process of test-driving a couple packages locally to make
>> sure that the new boost works. If that turns out well, I'll do a
>> non-scratch build of boost-1.46.0-0.beta1 later today.
> repoquery --archlist=src --repoid=rawhide-source -q \
> --whatrequires boost-devel | wc -l
> returns 163 for me.
I used this:
repoquery -s --whatrequires libboost\* | sort -u | wc -l
which returns actual src.rpm of packages that depend on one of boost
DSOs. There's 81 of them. Those are packages that really need
rebuilding against the new boost, because they won't work otherwise.
Packages that use header-only libraries linked essentially statically.
> On quick inspection, I didn't see too much in said list that's too
> critpath'y (though I did see some a couple of items low in the kde stack,
> akonadi and kdepimlibs), but wondering if this is worthy of introducing a
> side koji tag to do the necessary rebuilds.
I rebuilt the following locally:
aqsis needs a couple patches, I'll file a bug for that. The rest built
OK. I noticed that akonadi has a testsuite, which passed, and I played
and got my ass kicked by bastet, which means that it probably works. I
think that all means that the smoke test went rather OK.
One point that will cause problems (that's one aqsis patch) is that
boost::filesystem now defaults to V3 of the API, where before it
defaulted to V2. These APIs are not fully compatible. If the package
uses the functions that are missing in V3, the conservative thing to do
is to pass
in CXXFLAGS or to #define the same in appropriate places.
> It may also depend on the risk of api breakage here.
That's never too low with boost, but I wonder how much ABI changes can
one do in course of two weeks worth of bugfixing. (Again, I'm more
concerned about ABI breakages than API. Stuff will keep working in face
of the latter.)
More information about the devel