Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Merge Review: boost
------- Additional Comments From pertusus(a)free.fr 2007-04-10 08:47 EST -------
(In reply to comment #9)
1) why not use boost-jam for install?
It provides no advantage when we are doing staged builds, and also doesn't work
with prefix. In addition, it doesn't get the permissions correct. I'm not quite
sure why the permissions are incorrect in rpmlint considering they are
explicitly set by install to be the correct values. Any hacking by others in
this area would be appreciated.
I added a comment in my spec patch summarizing your point.
What upstream boost does with soname is dubious IMHO. In particular, boost libs
should not change SONAMES based on gcc versions if gcc versions are compat. Ie,
gcc-3.4, gcc-4.0, gcc-4.1 are compat. If using upstream boost versioning, they
In general, there is no ABI checking in upstream boost. Fedora does not have
Mostly, they leave this as a decision for vendors, one of whom is Fedora. The
plan WRT Fedora is to provide some guidance for people using older boosts that
are not ABI-compat with current boost. Thus the soname bump.
I don't understand exactly what you are meaning. With the current
patcheset, and without changing soname, the soname version used
is the boost version. This seems to be right, if you are saying that
"Fedora does not have the luxury to check the boost ABI change",
since it means that the soname has to be changed for every boost
In that case the library name could be like
the soname would be
and there would be a so link in devel
pointing to libboost_python.so.1.33.1
You may also be saying the reverse, namely that you check the ABI
compatibility and you don't break ABI for each release, that's why
you need a soname version that don't use the boost version, but
instead an integer you bump only when there has been an ABI
change. Is is the case?
(As a side note, even without boost-base.patch applied the gcc
version isn't hardcoded in the soname. The soname is like:
(or libboost_python-gcc-1_33_1.so.2 with <sonameversion>2 and
my patch or, I guess, the previous patch).)
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.