boost 1.46.0

Petr Machata 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[2] 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[1].
>>
>> 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:
akonadi-1.5.0-1.fc15.src.rpm
aqsis-1.6.0-5.fc14.src.rpm
asc-2.2.0.0-9.fc15.src.rpm
avogadro-1.0.1-11.fc15.src.rpm
barry-0.17-0.6.20110126git.fc15.src.rpm
bastet-0.43-8.fc15.src.rpm

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
   -DBOOST_FILESYSTEM_VERSION=2
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.)

PM


More information about the devel mailing list