[Bug 225622] Merge Review: boost

[bugzilla at redhat.com]

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


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225622





------- Additional Comments From pertusus at 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.

> 2) soname
> 
> 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
> are not. 
> 
> In general, there is no ABI checking in upstream boost. Fedora does not have
> this luxury.
>
> 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 
release.

In that case the library name could be like
libboost_python.so.1.33.1
the soname would be 
libboost_python.so.1.33.1
and there would be a so link in devel
libboost_python.so
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:
libboost_python-gcc-1_33_1.so.1.33.1
(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.