Bug 673839 - Review Request: boost141 - The free peer-reviewed portable C++ source libraries
Summary: Review Request: boost141 - The free peer-reviewed portable C++ source libraries
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matěj Cepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-30 20:29 UTC by Robert Scheck
Modified: 2018-04-11 09:08 UTC (History)
10 users (show)

Fixed In Version: boost141-1.41.0-2.el4
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 921134 (view as bug list)
Environment:
Last Closed: 2011-03-24 17:27:43 UTC
Type: ---
Embargoed:
mcepl: fedora-review+
j: fedora-cvs+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 768656 0 medium CLOSED Patch FindBoost.cmake in order to find the non-standard Boost-1.41 on EPEL 4/5 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 768657 0 medium CLOSED Boost.cmake specifies wrong paths 2021-02-22 00:41:40 UTC

Internal Links: 768657

Description Robert Scheck 2011-01-30 20:29:53 UTC
Spec URL: http://labs.linuxnetz.de/bugzilla/boost141.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/boost141-1.41.0-1.src.rpm
Description:
Boost provides free peer-reviewed portable C++ source libraries.  The
emphasis is on libraries which work well with the C++ Standard
Library, in the hopes of establishing "existing practice" for
extensions and providing reference implementations so that the Boost
libraries are suitable for eventual standardization. (Some of the
libraries have already been proposed for inclusion in the C++
Standards Committee's upcoming C++ Standard Library Technical Report.)


Zarafa 7.0.0 will require boost >= 1.35, which neither in EPEL 5 nor in
RHEL 5. RHEL 5 is only shipping the very old boost 1.31. This package is
boost-1.41.0-11 from RHEL 6, but transformed for parallel installation.
Boost 1.41 is not the newest one, but using the RHEL 6 package hopefully
lowers the maintainance overhead, because RHEL 6 has its end-of-lifetime
after RHEL 5.

Comment 1 Robert Scheck 2011-01-30 20:51:15 UTC
This package is intended to be only imported on EPEL <= 5, not at Fedora.

Comment 2 William Lima 2011-01-30 22:00:26 UTC
I suggest you to contact Benjamin Kosnik (bkoz) who is the Boost maintainer instead of doing this.

Comment 3 Robert Scheck 2011-01-30 22:12:05 UTC
William, why should I do this?

Newer versions of boost are (according to some upstream people, I'm not a C/
C++ guy) API incompatible and I'm pretty sure, Red Hat will not break API 
compatibility of boost.

And on the other hand, RHEL 5 is leaving the "Full Support" phase soon and
enters the "Deployment" or "Transition" phase afterwards, where such things
won't happen for sure.

So the only way, Red Hat might be walk for themself is like they did e.g. for 
postgresql (-> postgresql84) or php (-> php53). If such a thing will ever
happen, we still can obsolete this package.

I'm sorry, but I do not see a good reason to wait for the unlikely case that
Red Hat is doing this.

Comment 4 William Lima 2011-01-30 23:19:22 UTC
(In reply to comment #3)
> William, why should I do this?

Why not? He's the maintainer.

> Newer versions of boost are (according to some upstream people, I'm not a C/
> C++ guy) API incompatible and I'm pretty sure, Red Hat will not break API 
> compatibility of boost.

Yes, Boost had some interface changes and many of which are not backward compatible.

> So the only way, Red Hat might be walk for themself is like they did e.g. for 
> postgresql (-> postgresql84) or php (-> php53). If such a thing will ever
> happen, we still can obsolete this package.

Upgrade the existing package to a new version is the better way (instead of creating a new one), and should not affect existing packages.

I see no need for this. Just ask him to update.

Comment 5 Robert Scheck 2011-01-31 00:32:01 UTC
(In reply to comment #4)
> Yes, Boost had some interface changes and many of which are not backward
> compatible.

http://www.redhat.com/rhel/server/features/benefits.html with its section
"System API / ABI Compatibility and Stability" applies here...

> Upgrade the existing package to a new version is the better way (instead of
> creating a new one), and should not affect existing packages.
> 
> I see no need for this. Just ask him to update.

At first, he's on Cc: on this bug report now. Further more, RHEL updates do
not happen that easily - did you ever ask Red Hat for a rebase that is likely
to break API and/or ABI compatibility? For me, it looks like, you didn't...

At second, RHEL 5 ships boost-1.33.1-10.el5, if I'm not mistaken. If you read
http://pkgs.fedoraproject.org/gitweb/?p=boost.git;a=blob;f=boost.spec and the
changelog, you'll see that the SONAME was bumped multiple times in the past
to reflect the ABI changes. You know what ABI means? It will affect existing
packages - at least that is the very short form of this.

Comment 6 William Lima 2011-01-31 01:19:53 UTC
(In reply to comment #5)
> (In reply to comment #4)
> At first, he's on Cc: on this bug report now. Further more, RHEL updates do
> not happen that easily - did you ever ask Red Hat for a rebase that is likely
> to break API and/or ABI compatibility? For me, it looks like, you didn't...
> At second, RHEL 5 ships boost-1.33.1-10.el5, if I'm not mistaken. If you read
> http://pkgs.fedoraproject.org/gitweb/?p=boost.git;a=blob;f=boost.spec and the
> changelog, you'll see that the SONAME was bumped multiple times in the past
> to reflect the ABI changes. You know what ABI means? It will affect existing
> packages - at least that is the very short form of this.

there is no binary incompatibility between 1.33.1 and 1.35.0.

Comment 7 Robert Scheck 2011-01-31 01:59:15 UTC
Sure? Aside...RHEL 5 should get a more recent boost version anyway :)

1099 * Thu Aug 02 2007 Benjamin Kosnik <bkoz> 1.34.1-2
1100 - SONAME to 3.
[...]
1199 * Fri Aug 12 2005 Benjamin Kosnik <bkoz> 1.33.0-1
1200 - Update to boost-1.33.0, update SONAME to 2 due to ABI changes.
1201 - Simplified PYTHON_VERSION by Philipp Thomas <pth>

Comment 8 Matěj Cepl 2011-02-10 16:43:56 UTC
(In reply to comment #7)
> Sure? Aside...RHEL 5 should get a more recent boost version anyway :)

No, it won't (chat with boost maintainer)

[17:36:00] mcepl: Hi, I have a question about boost in RHEL-5. Is there any chance it would get rebased (or in words, could you comment please on https://bugzilla.redhat.com/show_bug.cgi?id=673839#c7)?
[17:36:16] bkoz: no need to look. It's not getting rebased
[17:36:54] mcepl: I am a bit involved in packaging Zarafa for RHEL-5, and it requires higher version of boost than what we have in RHEL-5. So, paralell package ... boost141 in EPEL, is I guess the only way, right?
[17:39:22] mcepl: also, can I post this chat to the bug?

[17:40:24] bkoz: can you bundle the boost version needed in the zarafa itself? look at the way monotone used to do this
[17:41:35] mcepl: well, it is not loved by the EPEL team and Packaging Guidelines I am afraid.
[17:43:00] bkoz: sure, you can post. There's no good solution here
[17:43:03] mcepl: we tried to suggest this option to EPEL folks and they were unequivocally against
[17:43:07] mcepl: OK, thanks

Comment 9 William Lima 2011-02-10 20:25:15 UTC
(In reply to comment #8)
> (In reply to comment #7)

[...]

> 
> [17:40:24] bkoz: can you bundle the boost version needed in the zarafa itself?
> look at the way monotone used to do this

[...]

+1 (bundle)

or leave the latest version of zarafa to RHEL 6 only.

Comment 10 Jason Tibbitts 2011-02-10 23:07:12 UTC
Bundling libraries is strongly discouraged.  If you really wish to do so, please see http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries.  You'll need to file a ticket with the packaging committee and provide answers to a number of questions.

Comment 11 Matěj Cepl 2011-02-12 22:20:01 UTC
- BAD : rpmlint is silent on both source and binary package.

It is not silent:
boost141-date-time.x86_64: W: invalid-url URL: http://sodium.resophonic.com/boost-cmake/1.41.0.cmake0/ <urlopen error timed out>
The value should be a valid, public HTTP, HTTPS, or FTP URL.
boost141-devel.x86_64: W: only-non-binary-in-usr-lib
There are only non binary files in /usr/lib so they should be in /usr/share.
boost141-graph-mpich2.x86_64: W: shared-lib-calls-exit /usr/lib64/mpich2/lib/libboost_graph_parallel.so.5 exit.5
This library package calls exit() or _exit(), probably in a non-fork()
context. Doing so from a library is strongly discouraged - when a library
function calls exit(), it prevents the calling program from handling the
error, reporting it to the user, closing files properly, and cleaning up any
state that the program has. It is preferred for the library to return an
actual error code and let the calling program decide how to handle the
situation.
boost141-math.x86_64: W: no-documentation
The package contains no documentation (README, doc, etc). You have to include
documentation files.
boost141.src:3: W: macro-in-comment %{_docdir}
There is a unescaped macro after a shell style comment in the specfile. Macros
are expanded everywhere, so check if it can cause a problem in this case and
escape the macro with another leading % if appropriate.
boost141.src:3: W: macro-in-comment %{name}
There is a unescaped macro after a shell style comment in the specfile. Macros
are expanded everywhere, so check if it can cause a problem in this case and
escape the macro with another leading % if appropriate.
boost141.src:3: W: macro-in-comment %{version}
There is a unescaped macro after a shell style comment in the specfile. Macros
are expanded everywhere, so check if it can cause a problem in this case and
escape the macro with another leading % if appropriate.
boost141.src:21: W: macro-in-comment %{_arch}
There is a unescaped macro after a shell style comment in the specfile. Macros
are expanded everywhere, so check if it can cause a problem in this case and
escape the macro with another leading % if appropriate.
boost141.src:546: W: mixed-use-of-spaces-and-tabs (spaces: line 402, tab: line 546)
The specfile mixes use of spaces and tabs for indentation, which is a cosmetic
annoyance.  Use either spaces or tabs for indentation, not both.
boost141.src: W: patch-not-applied Patch0: boost-cmake-soname.patch
A patch is included in your package but was not applied. Refer to the patches
documentation to see what's wrong.

I have tried couple of times to download source tarball from the Source0 URL and I was never succesful. Other issues should be IMHO addressed as well. I know, that this is just repackaging of Fedora package, so I believe help of the boost maintainer would be helpful as well.

+ GOOD: The package is named according to the Package Naming Guidelines .
+ GOOD: The spec file name matches the base package %{name}, in the format
  %{name}.spec.
+ GOOD: The package meets the Packaging Guidelines .
+ GOOD: The package is licensed with a Fedora approved license and meet the
Licensing Guidelines.
+ GOOD: The License field in the package spec file matches the actual license.

Well, not exactly. When just randomly opening boost/rational.hpp I found this pearl:

//  (C) Copyright Paul Moore 1999. Permission to copy, use, modify, sell and
//  distribute this software is granted provided this copyright notice appears
//  in all copies. This software is provided "as is" without express or
//  implied warranty, and with no claim as to its suitability for any purpose.

// boostinspect:nolicense (don't complain about the lack of a Boost license)
// (Paul Moore hasn't been in contact for years, so there's no way to change the
// license.)

This is probably OK, but packager should take a look at the licenses actually used in the package and change License field appropriately.

+ GOOD: LICENSE file is in %doc.
+ GOOD: The spec file is written in American English.
+ GOOD: The spec file for the package is legible.
- BAD : The sources used to build the package matches the upstream source,
as provided in the spec URL.
I was not able to get original sources.
+ GOOD: The package successfully compiles and build into binary rpms on at
least one supported architecture.
  Koji scratch build is
  http://koji.fedoraproject.org/koji/taskinfo?taskID=2830734
+ GOOD: builds on all architectures
+ GOOD: All build dependencies are listed in BuildRequires. (builds in koji)
+ GOOD: The spec file MUST handle locales properly.
  No locale support.
+ GOOD: %post and %postun scripts OK
+ GOOD: not relocatable
+ GOOD: A package owns all directories that it creates.
+ GOOD: A package must not contain any duplicate files in the %files listing.
+ GOOD: Permissions on files must be set properly.
+ GOOD: Each package have a %clean section.
+ GOOD: Each package consistently use macros.
+ GOOD: The package contains code, or permissable content.
+ GOOD: -doc subpackage provided.
+ GOOD: Files registered in %doc does not affect the runtime of the
application.
+ GOOD: No header files.
+ GOOD: No static libraries.
+ GOOD: No pkgconfig(.pc) files.
+ GOOD: .so file is provided in -devel package.
+ GOOD: Correct Requires in -devel subpackage.
+ GOOD: No .la libtool archives.
+ GOOD: Packages does not contain GUI applications.
+ GOOD: Packages does not own files or directories owned by other packages.
+ GOOD: Runs rm -rf $RPM_BUILD_ROOT in %install
+ GOOD: All filenames in rpm packages are valid UTF-8.
+ GOOD: Includes license text.

Please fix the above indicated problems.

Comment 12 Robert Scheck 2011-02-13 02:01:27 UTC
http://sodium.resophonic.com/boost-cmake/1.41.0.cmake0/ is at RHEL and older
Fedora versions used, because boost itself only ships bjam (and no makefiles!).
But bjam is somehow disliked by Fedora/Red Hat people. And the idea to provide 
just a patch-set containing the makefiles for cmake rather a whole tarball is
newer IIRC (that's how it is handled nowadays at Fedora).

I found the same tarball at the following two URLs, but I'm in doubt, whether
they are more permanent than the current one. Shall I add them as comment in
the spec file when updating it?

 - http://shr.bearstech.com/shr-unstable/sources/Boost/boost/
 - http://www.openpandora.org/firmware/sources/

Non-library files in %{_libdir} are required, because they're arch-specific;
this is IIRC solved the same way in Fedora at newer boost versions, too.

The macros in comments are IMHO rpmlint nonsense, escaping doesn't make things
more readable or really much better.

Warning regarding boost141-math seems irrelevant, as it is a meta-package only.

Warning regarding shared-lib-calls-exit seems acceptable to me, as it seems to
be called only in non-standard situation.

Regarding licensing: Current Boost package in Fedora has same license tag. If
you think, this should be verified, let's set FE_LEGAL and put Tom on Cc.

Comment 13 Robert Scheck 2011-02-13 21:58:39 UTC
http://gitorious.org/boost/cmake/archive-tarball/1.41.0.cmake0 is delivering
a tarball, which doesn't have same md5sum, but no diff-delta when comparing...

Comment 14 Robert Scheck 2011-02-13 22:10:21 UTC
Agreed with Matej on IRC that the next *.spec update will contain a comment
about why we are using another Source0 etc. and put in URL from comment #13
as reference and for verification.

Comment 15 Robert Scheck 2011-02-13 22:12:50 UTC
Tom, may you please have a look to the source code of boost regarding the
license? Please especially investigate to comment #11 at boost/rational.hpp.
Please also keep in mind, that RHEL 6 is actually shipping the same tarball.

Comment 16 Matěj Cepl 2011-02-13 22:25:49 UTC
BTW, concerning exit() in libboost_graph_parallel.so ... it is known in Debian (http://lintian.debian.org/tags/shlib-calls-exit.html), but they didn't do apparently anything about it, and I cannot find it in the upstream issue tracker (https://svn.boost.org/trac/) either.

Comment 17 Robert Scheck 2011-02-13 22:42:12 UTC
Regarding comment #16: Opened https://svn.boost.org/trac/boost/ticket/5185

Comment 18 Denis Arnaud 2011-02-14 13:55:35 UTC
Note that (sorted from the most recent to the oldest) bug #656410, bug #607615 and bug #529563 may be worth a look, as they track Fedora packaging for Boost.

FYI, we (Petr Machata and Benjamin Koznik, the official packagers, and I) are now packaging Boost-1.46 (or, at least, attempting to do so), thanks to a "cmake-ify" patch, which does the job. I do not see any reason why you could not re-use that work.

Of course, whether there will be an upgrade of Boost on RHEL/EPEL is another story...

Comment 19 Robert Scheck 2011-02-14 15:50:07 UTC
Denis, I'm sorry, but I'm not interested in creating new work to myself. That
is why I will stick with the version from RHEL 6 and not use Fedora as base.

Comment 20 Denis Arnaud 2011-02-15 12:03:27 UTC
(In reply to comment #19)
> Denis, I'm sorry, but I'm not interested in creating new work to myself.

I was not asking for help! Rather suggesting that most of the work you intend to do for yourself, may have already been done by others before.

Comment 21 Tom "spot" Callaway 2011-02-17 22:00:55 UTC
A quick audit shows:

Boost: too many to list
MIT: boost/multi_array/algorithm.hpp boost/interprocess/sync/interprocess_barrier.hpp boost/interprocess/sync/emulation/interprocess_recursive_mutex.hpp boost/interprocess/sync/interprocess_mutex.hpp boost/interprocess/sync/interprocess_recursive_mutex.hpp boost/interprocess/containers/container/list.hpp boost/interprocess/containers/container/map.hpp boost/interprocess/containers/container/vector.hpp boost/interprocess/containers/container/set.hpp boost/interprocess/containers/container/slist.hpp boost/interprocess/containers/container/string.hpp boost/interprocess/containers/container/detail/flat_tree.hpp boost/interprocess/containers/container/detail/tree.hpp boost/interprocess/containers/container/deque.hpp boost/interprocess/streams/vectorstream.hpp boost/interprocess/streams/bufferstream.hpp boost/interprocess/detail/move.hpp boost/wave/util/flex_string.hpp boost/program_options/detail/utf8_codecvt_facet.hpp boost/multi_index/ordered_index.hpp boost/multi_index/detail/ord_index_node.hpp boost/multi_index/detail/ord_index_ops.hpp boost/graph/kolmogorov_max_flow.hpp boost/graph/write_dimacs.hpp boost/function/detail/gen_maybe_include.pl boost/intrusive/rbtree_algorithms.hpp boost/detail/limits.hpp boost/detail/binary_search.hpp boost/detail/algorithm.hpp libs/interprocess/test/condition_test_template.hpp 
libs/interprocess/test/util.hpp libs/interprocess/test/mutex_test_template.hpp 
boost/shared_container_iterator.hpp boost/rational.hpp 

BSD: libs/wave/test/testwave/testfiles/t_6_027.cpp libs/wave/test/testwave/testfiles/t_6_005.cpp libs/wave/test/testwave/testfiles/t_5_009.cpp libs/wave/test/testwave/testfiles/t_6_064.cpp libs/wave/test/testwave/testfiles/t_6_009.cpp libs/wave/test/testwave/testfiles/t_5_035_11.hpp libs/wave/test/testwave/testfiles/t_5_022.cpp libs/wave/test/testwave/testfiles/t_6_011.cpp (and several more testfiles in libs/wave/test/testwave/testfiles/ that I got tired of enumerating)

Python: boost/python/detail/python22_fixed.h

So, there are four licenses in play here: Boost, MIT, BSD, and Python

The BSD files are only involved in the libs/wave/test code, which I do not believe end up being packaged in any way (don't get built into a binary or library either).

The Python file is only used for the python bindings.

So, the overall license tag should be: License: Boost and MIT

The -python subpackage should be: License: Boost and MIT and Python

Lifting FE-Legal.

Comment 23 Matěj Cepl 2011-03-08 10:36:35 UTC
APPROVED!

Comment 24 Robert Scheck 2011-03-08 12:35:19 UTC
Matej, thank you for the review!


New Package SCM Request
=======================
Package Name: boost141
Short Description: The free peer-reviewed portable C++ source libraries
Owners: robert
Branches: el5
InitialCC: 

Whoever is handling the SCM request: If it's possible to skip creation of the
devel branch, please do so. This package is EPEL 5-only. Otherwise I am going
to orphan it afterwards simply.

Comment 25 Jason Tibbitts 2011-03-08 20:53:47 UTC
Git done (by process-git-requests).

Comment 26 Fedora Update System 2011-03-08 22:40:55 UTC
boost141-1.41.0-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/boost141-1.41.0-2.el5

Comment 27 Fedora Update System 2011-03-09 18:27:49 UTC
boost141-1.41.0-2.el5 has been pushed to the Fedora EPEL 5 testing repository.

Comment 28 Robert Scheck 2011-03-13 18:57:23 UTC
Zarafa upstream decided to backport some Zarafa 7 features into the stable
6.40.x series. Thus boost141 is now required on EPEL 4, too.


Package Change Request
======================
Package Name: boost141
New Branches: el4
Owners: robert

Comment 29 Jason Tibbitts 2011-03-14 01:04:49 UTC
Git done (by process-git-requests).

Comment 30 Fedora Update System 2011-03-14 01:41:41 UTC
boost141-1.41.0-2.el4 has been submitted as an update for Fedora EPEL 4.
https://admin.fedoraproject.org/updates/boost141-1.41.0-2.el4

Comment 31 Fedora Update System 2011-03-24 17:27:37 UTC
boost141-1.41.0-2.el5 has been pushed to the Fedora EPEL 5 stable repository.

Comment 32 Fedora Update System 2011-03-28 17:29:41 UTC
boost141-1.41.0-2.el4 has been pushed to the Fedora EPEL 4 stable repository.


Note You need to log in before you can comment on or make changes to this bug.