Boost RPM spec file: Take 2
Several weeks ago, I posted an RPM spec file for Boost that I was hoping to see used as the "upstream" spec file for Boost installations on RPM-based Linux distributions. If nothing else, having it serve as a model to Linux distributors would be great, too. I have attached an updated version of that spec file that I feel is an improvement to the earlier version. The philosophy behind this new spec file is to be as true as possible to what I understand to be a "normal" Boost installation. I realize that users are afforded many ways to customize their Boost installation through different build-time options. Without doing any build customization, however, a Boost installation has single- and multi-threaded variants of libraries, both static and dynamic, that are named based on the toolset used for building and the Boost version number. Furthermore, the headers are installed in a versioned subdirectory. All of this allows parallel installations of different Boost build variants, and I see that as an extremely powerful capability. The attached RPM spec file leverages that in a way that I see as being very valuable. Relative to the Boost RPM distributed for use on Red Hat distributions of Linux (I do not have experience with pre-packaged versions of Boost from other Linux distribution vendors, so I cannot comment on how they do things), this RPM spec file has the following benefits: * Allows parallel installations of multiple Boost releases (both the run-time RPM and the developer RPM) * Installs single- and multi-threaded builds of libraries The spec file that Red Hat uses for building Boost RPMs removes the toolset name and the version information from the base name of the library, and it only installs the single-threaded build of each library. For reasons that are not yet clear to me, an additional symlink is created for each Boost shared library named libboost_<libname>.so.2 that points to libboost_<libname>.so.1.33.1. This prevents multiple parallel run-time installations. Multiple developer installations are prevented by the removal of the version information from the base library name and by the fact that the headers are placed in /usr/include/boost instead of in /usr/include/boost-1_33_1/boost. Since there are likely to be many users who are expecting Boost to be installed using the Red Hat RPM, I have added some compatibility bits in the form of two extra RPMs called boost-symlinks and boost-devel-symlinks. The first installs symlinks for the Boost libraries named using Red Hat's stripped down convention (with the version number after the .so part of the name). The second RPM installs unversioned symbolic links to the fully qualified library names and to the Boost header directory. The idea here is that users could have multiple Boost developer installations in parallel, and if they so desired, they could install this extra RPM with unversioned names to point to whichever Boost installation should be the "default" version. Since the symlinks are unversioned, parallel installations of multiple versions of these RPMs is not possible. Nevertheless, the two together provide a means to make a Boost RPM installation that is compatible with what Red Hat has been distributing for quite a while now. Comments? -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/ %define version 1.33.1 %define underscore_version %(echo %{version} | sed -e 's/\\./_/g') %define last_version 1.33.0 %define tarball_name boost_%{underscore_version} %define release 2 %define python_arch %(python -c 'import os; print os.uname()[4]') %if %{python_arch} == %{_arch} %define build_python 1 %else %define build_python 0 %endif Name: boost Summary: The Boost C++ Libraries Version: %{version} Release: %{release} License: Boost Software License URL: http://www.boost.org/ Group: System Environment/Libraries Source: %{tarball_name}.tar.bz2 BuildRoot: %{_tmppath}/boost-%{version}-root Prereq: /sbin/ldconfig %if %{build_python} BuildRequires: libstdc++-devel python %else BuildRequires: libstdc++-devel %endif Obsoletes: boost <= %{last_version} Obsoletes: boost-devel <= %{last_version} Obsoletes: boost-doc <= %{last_version} %if %{build_python} Obsoletes: boost-python <= %{last_version} %endif %description Boost provides free peer-reviewed portable C++ source libraries. The emphasis is on libraries which work well with the C++ Standard Library. One goal is to establish "existing practice" and provide 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.) %package devel Summary: The Boost C++ Headers Group: System Environment/Libraries Requires: boost = %{version}-%{release} %if %{build_python} Obsoletes: boost-python-devel <= %{last_version} Provides: boost-python-devel = %{version}-%{release} %endif %description devel Headers and libraries for developing software that uses Boost C++. %package symlinks Summary: Compatibility Links to the Boost C++ %{version} Libraries Group: System Environment/Libraries Requires: boost = %{version}-%{release} %description symlinks Symllinks to the Boost %{version} libraries for compatibility with Boost RPMs distributed by Red Hat. %package devel-symlinks Summary: Unversioned Links to the Boost C++ %{version} Headers Group: System Environment/Libraries Requires: boost = %{version}-%{release} Requires: boost-devel = %{version}-%{release} %description devel-symlinks Unversioned symllinks to the Boost %{version} headers and libraries for compatibility with Boost RPMs distributed by Red Hat. %package doc Summary: The Boost C++ HTML docs Group: System Environment/Libraries Requires: boost = %{version}-%{release} %if %{build_python} Provides: boost-python-docs = %{version}-%{release} %endif %description doc HTML documentation files for Boost C++ libraries %prep rm -rf $RPM_BUILD_ROOT %setup -n %{tarball_name} -q %ifarch i386 i486 i586 i686 %define arch_args <cflags>-m32 <cxxflags>-m32 <linkflags>-m32 <linkflags>-L/usr/lib %else %ifarch x86_64 %define arch_args <cflags>-m64 <cxxflags>-m64 <linkflags>-m64 <linkflags>-L/usr/lib64 %endif %endif %build if icu-config --ldflags ; then export ICU_PATH=/usr ICU_LINK=\"$(icu-config --ldflags | sed 's/-lpthread//g')\"; fi without_libs='' %if %{build_python} == 0 without_libs="$without_libs --without-python" %endif # This is a hack. A better way needs to be devised for determining when # the local architecture does not match the target architecture. %if %{python_arch} != %{_arch} without_libs="$without_libs --without-iostreams" %endif #build bjam (cd tools/build/jam_src && ./build.sh) #build boost with bjam BJAM=`find tools/build/jam_src/ -name bjam -a -type f` PYTHON_VERSION=`python -V 2>&1 |sed 's,.* \([0-9]\.[0-9]\)\(\.[0-9]\)\?.*,\1,'` PYTHON_FLAGS="-sPYTHON_ROOT=/usr -sPYTHON_VERSION=$PYTHON_VERSION" $BJAM $PYTHON_FLAGS "-sTOOLS=gcc" "-sBUILD=release <threading>single/multi %{arch_args}" "--prefix=$RPM_BUILD_ROOT%{_prefix}" "--libdir=$RPM_BUILD_ROOT%{_libdir}" $without_libs install %install curdir=`pwd` cd $RPM_BUILD_ROOT%{_includedir} ln -s boost-%{underscore_version}/boost ./boost # Replace unversioned static and shared libraries with symlinks to the # versioned copy. The symlinks will be packaged separately for people who want # to use an unversioned Boost developer environment. This also prevents # ldconfig from complaining about duplicate shared libraries. # Create symlinks to the fully qualified library without the toolset name for # compatibility with other Boost RPMs. cd $RPM_BUILD_ROOT%{_libdir} for f in libboost_*-%{underscore_version}.so ; do unversioned_name=`echo $f | sed -e 's/-%{underscore_version}//'` no_info_name=`echo $unversioned_name | sed -e 's/-gcc//'` rm -f $unversioned_name ln -s $f.%{version} $unversioned_name ln -s $f.%{version} $no_info_name ln -s $f.%{version} $no_info_name.%{version} ln -s $f.%{version} $no_info_name.2 done for f in libboost_*-%{underscore_version}.a ; do unversioned_name=`echo $f | sed -e 's/-%{underscore_version}//'` no_info_name=`echo $unversioned_name | sed -e 's/-gcc//'` rm -f $unversioned_name ln -s $f $unversioned_name ln -s $f $no_info_name done cd $curdir #install doc files mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version} #cp -a doc/html $RPM_BUILD_ROOT/%{_docdir}/%{name}-%{version} find . -name '*.html' -o -name '*.css' -o -name '*.htm' | cpio -p --make-directories $RPM_BUILD_ROOT/%{_docdir}/%{name}-%{version} find $RPM_BUILD_ROOT/%{_docdir}/%{name}-%{version} -type d | xargs chmod 755 find $RPM_BUILD_ROOT/%{_docdir}/%{name}-%{version} -type f | xargs chmod 644 %clean rm -rf $RPM_BUILD_ROOT %post /sbin/ldconfig %postun /sbin/ldconfig %files %defattr(-, root, root) %{_libdir}/*-%{underscore_version}.so.%{version} %files symlinks %defattr(-, root, root) %{_libdir}/*[a-z].so.%{version} %{_libdir}/*[a-z].so.2 %files devel %defattr(-, root, root) %{_includedir}/boost-%{underscore_version} %{_libdir}/*-%{underscore_version}.a %{_libdir}/*-%{underscore_version}.so %files devel-symlinks %defattr(-, root, root) %{_includedir}/boost %{_libdir}/*[a-z].a %{_libdir}/*[a-z].so %files doc %defattr(-, root, root) %{_docdir}/boost-%{version} %changelog * Wed Aug 9 2006 Patrick Hartling <patrick@infiscape.com> 1.33.1-2 - Put headers in versioned subdirectory - Simplify build/installation process - Fixed complaints from ldconfig about duplicate shared libraries - Use symbolic links for unversioned header directory and library files for compability with Red Hat RPMs (see the new packages symlinks and devel-symlinks) * Fri Apr 14 2006 Patrick Hartling <patrick@infiscape.com> 1.33.1-1 - Update to 1.33.1 - Install single- and multi-threaded libraries - Install fully versioned libraries - Allow 32-bit build to be made on 64-bit architecture (currently without Boost.Python or Boost.iostreams) * Mon Nov 29 2004 Benjamin Kosnik <bkoz@redhat.com> 1.32.0-1 - Update to 1.32.0 - (#122817: libboost_*.so symlinks missing) * Wed Sep 22 2004 Than Ngo <than@redhat.com> 1.31.0-9 - cleanup specfile - fix multiarch problem * Tue Jun 15 2004 Elliot Lee <sopwith@redhat.com> - rebuilt * Wed May 05 2004 Warren Togami <wtogami@redhat.com> 1.31.0-7 - missing Obsoletes boost-python * Mon May 03 2004 Benjamin Kosnik <bkoz@redhat.com> - (#121630: gcc34 patch needed) * Wed Apr 21 2004 Warren Togami <wtogami@redhat.com> - #121415 FC2 BLOCKER: Obsoletes boost-python-devel, boost-doc - other cleanups * Tue Mar 30 2004 Benjamin Kosnik <bkoz@redhat.com> - Remove bjam dependency. (via Graydon). - Fix installed library names. - Fix SONAMEs in shared libraries. - Fix installed header location. - Fix installed permissions. * Fri Feb 13 2004 Elliot Lee <sopwith@redhat.com> - rebuilt * Mon Feb 09 2004 Benjamin Kosnik <bkoz@redhat.com> 1.31.0-2 - Update to boost-1.31.0 * Thu Jan 22 2004 Benjamin Kosnik <bkoz@redhat.com> 1.31.0-1 - Update to boost-1.31.0.rc2 - (#109307: Compile Failure with boost libraries) - (#104831: Compile errors in apps using Boost.Python...) - Unify into boost, boost-devel rpms. - Simplify installation using bjam and prefix install. * Tue Sep 09 2003 Nalin Dahyabhai <nalin@redhat.com> 1.30.2-2 - require boost-devel instead of devel in subpackages which require boost-devel - remove stray Prefix: tag * Mon Sep 08 2003 Benjamin Kosnik <bkoz@redhat.com> 1.30.2-1 - change license to Freely distributable - verify installation of libboost_thread - more boost-devel removals - deal with lack of _REENTRANT on ia64/s390 - (#99458) rpm -e fixed via explict dir additions - (#103293) update to 1.30.2 * Wed Jun 04 2003 Elliot Lee <sopwith@redhat.com> - rebuilt * Tue May 13 2003 Florian La Roche <Florian.LaRoche@redhat.de> - remove packager, change to new Group: * Tue May 06 2003 Tim Powers <timp@redhat.com> 1.30.0-3 - add deffattr's so we don't have unknown users owning files
Patrick Hartling wrote:
Several weeks ago, I posted an RPM spec file for Boost that I was hoping to see used as the "upstream" spec file for Boost installations on RPM-based Linux distributions. If nothing else, having it serve as a model to Linux distributors would be great, too. I have attached an updated version of that spec file that I feel is an improvement to the earlier version.
The philosophy behind this new spec file is to be as true as possible to what I understand to be a "normal" Boost installation. I realize that users are afforded many ways to customize their Boost installation through different build-time options. Without doing any build customization, however, a Boost installation has single- and multi-threaded variants of libraries, both static and dynamic, that are named based on the toolset used for building and the Boost version number. Furthermore, the headers are installed in a versioned subdirectory. All of this allows parallel installations of different Boost build variants, and I see that as an extremely powerful capability. The attached RPM spec file leverages that in a way that I see as being very valuable.
Relative to the Boost RPM distributed for use on Red Hat distributions of Linux (I do not have experience with pre-packaged versions of Boost from other Linux distribution vendors, so I cannot comment on how they do things), this RPM spec file has the following benefits:
* Allows parallel installations of multiple Boost releases (both the run-time RPM and the developer RPM) * Installs single- and multi-threaded builds of libraries
The spec file that Red Hat uses for building Boost RPMs removes the toolset name and the version information from the base name of the library, and it only installs the single-threaded build of each library. For reasons that are not yet clear to me, an additional symlink is created for each Boost shared library named libboost_<libname>.so.2 that points to libboost_<libname>.so.1.33.1. This prevents multiple parallel run-time installations. Multiple developer installations are prevented by the removal of the version information from the base library name and by the fact that the headers are placed in /usr/include/boost instead of in /usr/include/boost-1_33_1/boost.
Since there are likely to be many users who are expecting Boost to be installed using the Red Hat RPM, I have added some compatibility bits in the form of two extra RPMs called boost-symlinks and boost-devel-symlinks. The first installs symlinks for the Boost libraries named using Red Hat's stripped down convention (with the version number after the .so part of the name). The second RPM installs unversioned symbolic links to the fully qualified library names and to the Boost header directory. The idea here is that users could have multiple Boost developer installations in parallel, and if they so desired, they could install this extra RPM with unversioned names to point to whichever Boost installation should be the "default" version. Since the symlinks are unversioned, parallel installations of multiple versions of these RPMs is not possible. Nevertheless, the two together provide a means to make a Boost RPM installation that is compatible with what Red Hat has been distributing for quite a while now.
Comments?
-Patrick
I have taken some similar approach. I put includes in a parallel dir, but I also put libs in a parallel dir. This prevents any conflicts. If you do this, you don't need a seperate symlink package, right? Since Redhat will produce %{_libdir}/libboost_regex.so.1.33.1 and so might you, don't you have to use a different libdir? Another issue, right now, Redhat is using libboost_regex.so.2. If you run ldconfig, won't it change your symlink to point to the highest version number, which might not be what you want? I don't know why there is arch_args. When building on x86_64 you don't need to use -m64 - that's the default. Is this so you can build the i386 rpm on an x86_64 host? Not that it hurts anything.
Neal Becker wrote:
Patrick Hartling wrote:
Several weeks ago, I posted an RPM spec file for Boost that I was hoping to see used as the "upstream" spec file for Boost installations on RPM-based Linux distributions. If nothing else, having it serve as a model to Linux distributors would be great, too. I have attached an updated version of that spec file that I feel is an improvement to the earlier version.
The philosophy behind this new spec file is to be as true as possible to what I understand to be a "normal" Boost installation. I realize that users are afforded many ways to customize their Boost installation through different build-time options. Without doing any build customization, however, a Boost installation has single- and multi-threaded variants of libraries, both static and dynamic, that are named based on the toolset used for building and the Boost version number. Furthermore, the headers are installed in a versioned subdirectory. All of this allows parallel installations of different Boost build variants, and I see that as an extremely powerful capability. The attached RPM spec file leverages that in a way that I see as being very valuable.
Relative to the Boost RPM distributed for use on Red Hat distributions of Linux (I do not have experience with pre-packaged versions of Boost from other Linux distribution vendors, so I cannot comment on how they do things), this RPM spec file has the following benefits:
* Allows parallel installations of multiple Boost releases (both the run-time RPM and the developer RPM) * Installs single- and multi-threaded builds of libraries
The spec file that Red Hat uses for building Boost RPMs removes the toolset name and the version information from the base name of the library, and it only installs the single-threaded build of each library. For reasons that are not yet clear to me, an additional symlink is created for each Boost shared library named libboost_<libname>.so.2 that points to libboost_<libname>.so.1.33.1. This prevents multiple parallel run-time installations. Multiple developer installations are prevented by the removal of the version information from the base library name and by the fact that the headers are placed in /usr/include/boost instead of in /usr/include/boost-1_33_1/boost.
Since there are likely to be many users who are expecting Boost to be installed using the Red Hat RPM, I have added some compatibility bits in the form of two extra RPMs called boost-symlinks and boost-devel-symlinks. The first installs symlinks for the Boost libraries named using Red Hat's stripped down convention (with the version number after the .so part of the name). The second RPM installs unversioned symbolic links to the fully qualified library names and to the Boost header directory. The idea here is that users could have multiple Boost developer installations in parallel, and if they so desired, they could install this extra RPM with unversioned names to point to whichever Boost installation should be the "default" version. Since the symlinks are unversioned, parallel installations of multiple versions of these RPMs is not possible. Nevertheless, the two together provide a means to make a Boost RPM installation that is compatible with what Red Hat has been distributing for quite a while now.
Comments?
-Patrick
I have taken some similar approach. I put includes in a parallel dir, but I also put libs in a parallel dir. This prevents any conflicts. If you do this, you don't need a seperate symlink package, right?
Yes, that is true. I didn't notice that detail in your spec file. That is certainly an interesting idea since ldconfig should take care of extending the default search path, right?
Since Redhat will produce %{_libdir}/libboost_regex.so.1.33.1 and so might you, don't you have to use a different libdir?
My intention was to produce RPMs that can be used in place of those from Red Hat while still providing the same file names and directory structure for people who want that. Personally, I want to use the fully qualified library names because it facilitates parallel installations so well. This is important for my company's goals since we want to install long-lived software on customers' computers and be able to make easy patches/upgrades along the way. If the focus changes such that this spec file is for making a Boost installation that can live along side the one made by Red Hat, then several aspects of the spec file would change.
Another issue, right now, Redhat is using libboost_regex.so.2. If you run ldconfig, won't it change your symlink to point to the highest version number, which might not be what you want?
Good point. I need to read up on ldconfig more and understand exactly what the goal of installing libboost_*.so.2 is.
I don't know why there is arch_args. When building on x86_64 you don't need to use -m64 - that's the default. Is this so you can build the i386 rpm on an x86_64 host? Not that it hurts anything.
Yes, that's why that is in there. Back in April when I was making a bunch of spec files for a customer installation, I needed to be able to target both i386 and x86_64 from an x86_64 machine. As a result, just about all the spec files I wrote at that time have this provision. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
Patrick Hartling wrote:
Neal Becker wrote:
Patrick Hartling wrote:
Several weeks ago, I posted an RPM spec file for Boost that I was hoping to see used as the "upstream" spec file for Boost installations on RPM-based Linux distributions. If nothing else, having it serve as a model to Linux distributors would be great, too. I have attached an updated version of that spec file that I feel is an improvement to the earlier version.
The philosophy behind this new spec file is to be as true as possible to what I understand to be a "normal" Boost installation. I realize that users are afforded many ways to customize their Boost installation through different build-time options. Without doing any build customization, however, a Boost installation has single- and multi-threaded variants of libraries, both static and dynamic, that are named based on the toolset used for building and the Boost version number. Furthermore, the headers are installed in a versioned subdirectory. All of this allows parallel installations of different Boost build variants, and I see that as an extremely powerful capability. The attached RPM spec file leverages that in a way that I see as being very valuable.
Relative to the Boost RPM distributed for use on Red Hat distributions of Linux (I do not have experience with pre-packaged versions of Boost from other Linux distribution vendors, so I cannot comment on how they do things), this RPM spec file has the following benefits:
* Allows parallel installations of multiple Boost releases (both the run-time RPM and the developer RPM) * Installs single- and multi-threaded builds of libraries
The spec file that Red Hat uses for building Boost RPMs removes the toolset name and the version information from the base name of the library, and it only installs the single-threaded build of each library. For reasons that are not yet clear to me, an additional symlink is created for each Boost shared library named libboost_<libname>.so.2 that points to libboost_<libname>.so.1.33.1. This prevents multiple parallel run-time installations. Multiple developer installations are prevented by the removal of the version information from the base library name and by the fact that the headers are placed in /usr/include/boost instead of in /usr/include/boost-1_33_1/boost.
Since there are likely to be many users who are expecting Boost to be installed using the Red Hat RPM, I have added some compatibility bits in the form of two extra RPMs called boost-symlinks and boost-devel-symlinks. The first installs symlinks for the Boost libraries named using Red Hat's stripped down convention (with the version number after the .so part of the name). The second RPM installs unversioned symbolic links to the fully qualified library names and to the Boost header directory. The idea here is that users could have multiple Boost developer installations in parallel, and if they so desired, they could install this extra RPM with unversioned names to point to whichever Boost installation should be the "default" version. Since the symlinks are unversioned, parallel installations of multiple versions of these RPMs is not possible. Nevertheless, the two together provide a means to make a Boost RPM installation that is compatible with what Red Hat has been distributing for quite a while now.
Comments?
-Patrick
I have taken some similar approach. I put includes in a parallel dir, but I also put libs in a parallel dir. This prevents any conflicts. If you do this, you don't need a seperate symlink package, right?
Yes, that is true. I didn't notice that detail in your spec file. That is certainly an interesting idea since ldconfig should take care of extending the default search path, right?
Not sure what you mean by ldconfig extending search path. ldconfig can be told about new search path. In recent fedoras, we have /etc/ld.so.conf.d. All you need to do is have your rpm drop a file in this directory, and search path is extended.
Since Redhat will produce %{_libdir}/libboost_regex.so.1.33.1 and so might you, don't you have to use a different libdir?
My intention was to produce RPMs that can be used in place of those from Red Hat while still providing the same file names and directory structure for people who want that. Personally, I want to use the fully qualified library names because it facilitates parallel installations so well. This is important for my company's goals since we want to install long-lived software on customers' computers and be able to make easy patches/upgrades along the way. If the focus changes such that this spec file is for making a Boost installation that can live along side the one made by Red Hat, then several aspects of the spec file would change.
So, the suggestion is that redhat will produce e.g., %{_libdir}/libboost_regex.so.1.33.1 and that the proposed package will also produce %{_libdir}/libboost_regex.so.1.33.1, so they will conflict? Maybe I misunderstood. AFAIK, a parallel install is the way to go.
Neal Becker wrote:
Patrick Hartling wrote:
Neal Becker wrote:
Patrick Hartling wrote:
[snip]
Since there are likely to be many users who are expecting Boost to be installed using the Red Hat RPM, I have added some compatibility bits in the form of two extra RPMs called boost-symlinks and boost-devel-symlinks. The first installs symlinks for the Boost libraries named using Red Hat's stripped down convention (with the version number after the .so part of the name). The second RPM installs unversioned symbolic links to the fully qualified library names and to the Boost header directory. The idea here is that users could have multiple Boost developer installations in parallel, and if they so desired, they could install this extra RPM with unversioned names to point to whichever Boost installation should be the "default" version. Since the symlinks are unversioned, parallel installations of multiple versions of these RPMs is not possible. Nevertheless, the two together provide a means to make a Boost RPM installation that is compatible with what Red Hat has been distributing for quite a while now.
Comments?
-Patrick
I have taken some similar approach. I put includes in a parallel dir, but I also put libs in a parallel dir. This prevents any conflicts. If you do this, you don't need a seperate symlink package, right? Yes, that is true. I didn't notice that detail in your spec file. That is certainly an interesting idea since ldconfig should take care of extending the default search path, right?
Not sure what you mean by ldconfig extending search path. ldconfig can be told about new search path. In recent fedoras, we have /etc/ld.so.conf.d. All you need to do is have your rpm drop a file in this directory, and search path is extended.
I was referring to ldconfig being told about directories other than the trusted set so that users do not have to set/extend $LD_LIBRARY_PATH in order to find shared libraries that are not in those directories. I know that that's how it works on FreeBSD. It isn't clear to me from the ldconfig man page on Enterprise Linux 4 that the Linux version does the same thing, but I think it must in order for things such as the Qt libraries to be found without extra effort on the part of the user.
Since Redhat will produce %{_libdir}/libboost_regex.so.1.33.1 and so might you, don't you have to use a different libdir? My intention was to produce RPMs that can be used in place of those from Red Hat while still providing the same file names and directory structure for people who want that. Personally, I want to use the fully qualified library names because it facilitates parallel installations so well. This is important for my company's goals since we want to install long-lived software on customers' computers and be able to make easy patches/upgrades along the way. If the focus changes such that this spec file is for making a Boost installation that can live along side the one made by Red Hat, then several aspects of the spec file would change.
So, the suggestion is that redhat will produce e.g., %{_libdir}/libboost_regex.so.1.33.1 and that the proposed package will also produce %{_libdir}/libboost_regex.so.1.33.1, so they will conflict? Maybe I misunderstood. AFAIK, a parallel install is the way to go.
Yes, installing boost-symlinks would conflict with the boost RPM that Red Hat makes. My intention, however, is to replace the Red Hat RPM, rather than to live alongside it. The -symlinks packages are to provide a means to be compatible with the naming used by the RPM used by Red Hat. Ultimately, what I would prefer to see is Red Hat using an installation scheme for Boost that more closely follows the model that Boost uses, but I do not know that anyone else necessarily feels that way. Certainly, in the time that Red Hat has been distributing Boost with Enterprise Linux and Fedora Core, they must not have gotten many--if any--reports of people wanting the Boost packaging to change. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
* Neal Becker (ndbecker2@gmail.com) [20060809 23:29]:
If you run ldconfig, won't it change your symlink to point to the highest version number, which might not be what you want?
No it won't. ldconfig only creats symlinks to the soname of a shared library. So you get that symlink only if any of the boost libraries has a soname of libboost.so.2. I haven't tried what happens if more then one library has the same soname, but I'd guess the last library checked wins. Philipp
Patrick Hartling wrote:
Several weeks ago, I posted an RPM spec file for Boost that I was hoping to see used as the "upstream" spec file for Boost installations on RPM-based Linux distributions. If nothing else, having it serve as a model to Linux distributors would be great, too. I have attached an updated version of that spec file that I feel is an improvement to the earlier version.
<snipped>
Comments?
Modulo the comment of Neil Becker, this looks like it's on the right track. I don't have the time to test this right now, but an official Boost rpm file has been on my wish list for a while, so please do continue to persue this one :-) Thanks, John.
Patrick Hartling wrote:
The philosophy behind this new spec file is to be as true as possible to what I understand to be a "normal" Boost installation. I realize that users are afforded many ways to customize their Boost installation through different build-time options. Without doing any build customization, however, a Boost installation has single- and multi-threaded variants of libraries, both static and dynamic, that are named based on the toolset used for building and the Boost version number. Furthermore, the headers are installed in a versioned subdirectory. All of this allows parallel installations of different Boost build variants, and I see that as an extremely powerful capability.
I am mostly a lurker on the Boost list, but the above strikes me as odd. The point of installing a library as an RPM package is to satisfy the dependencies for other installed packages, not to make it available to a software developer. Similarly, the corresponding development package is intended to facilitate the packaging by making sure that the source code gets compiled against the same set of choices which are embedded in the RPM package found on the destination host, so that saying "Requires: boost" in the .spec file has a good chance of working. Software developers can readily install multiple versions in their home directories, or even dedicate seperate accounts to separate versions, so I am not seeing the benefit of the above (except for developers using RPM to manage software in their home directory: an interesting thought).
Relative to the Boost RPM distributed for use on Red Hat distributions of Linux (I do not have experience with pre-packaged versions of Boost from other Linux distribution vendors, so I cannot comment on how they do things), this RPM spec file has the following benefits:
* Allows parallel installations of multiple Boost releases (both the run-time RPM and the developer RPM) * Installs single- and multi-threaded builds of libraries
The spec file that Red Hat uses for building Boost RPMs removes the toolset name and the version information from the base name of the library, and it only installs the single-threaded build of each library. For reasons that are not yet clear to me, an additional symlink is created for each Boost shared library named libboost_<libname>.so.2 that points to libboost_<libname>.so.1.33.1.
I guess this is meant to address the "broken promise" problem: if boost.so.1.33 were not fully ABI compatible with boost.so.1.32, it was necessary to label boost.so.1.33 with a SONAME of boost.so.2 so that applications linked against boost.so.1.32 would not attempt to load it and crash. By the way, this leads me to think (I have not checked) that the packages are either (a) already *are* installable side by side, if the SONAME is different, or (b) must be prevented from being available at the same time, if the SONAME is the same.
This prevents multiple parallel run-time installations. Multiple developer installations are prevented by the removal of the version information from the base library name and by the fact that the headers are placed in /usr/include/boost instead of in /usr/include/boost-1_33_1/boost.
If multiple developer installations exist, where does the development symlink point to ? More to the point: if it does not point to the library provided by Red Hat, I am in trouble.
The second RPM installs unversioned symbolic links to the fully qualified library names and to the Boost header directory. The idea here is that users could have multiple Boost developer installations in parallel, and if they so desired, they could install this extra RPM with unversioned names to point to whichever Boost installation should be the "default" version. Since the symlinks are unversioned, parallel installations of multiple versions of these RPMs is not possible. Nevertheless, the two together provide a means to make a Boost RPM installation that is compatible with what Red Hat has been distributing for quite a while now.
Did you consider contacting the people at Red Hat managing the packaging of Boost ? It might be just me, but the above is ... uncustomary. Are you trying to follow standard shared library versioning, or do you mean to handcraft what libtool does ? Davide Bolcioni -- There is no place like /home.
Davide Bolcioni wrote:
Patrick Hartling wrote:
The philosophy behind this new spec file is to be as true as possible to what I understand to be a "normal" Boost installation. I realize that users are afforded many ways to customize their Boost installation through different build-time options. Without doing any build customization, however, a Boost installation has single- and multi-threaded variants of libraries, both static and dynamic, that are named based on the toolset used for building and the Boost version number. Furthermore, the headers are installed in a versioned subdirectory. All of this allows parallel installations of different Boost build variants, and I see that as an extremely powerful capability.
I am mostly a lurker on the Boost list, but the above strikes me as odd.
The point of installing a library as an RPM package is to satisfy the dependencies for other installed packages, not to make it available to a software developer. Similarly, the corresponding development package is intended to facilitate the packaging by making sure that the source code gets compiled against the same set of choices which are embedded in the RPM package found on the destination host, so that saying "Requires: boost" in the .spec file has a good chance of working.
Software developers can readily install multiple versions in their home directories, or even dedicate seperate accounts to separate versions, so I am not seeing the benefit of the above (except for developers using RPM to manage software in their home directory: an interesting thought).
You are right, this is possible. Using package management to deploy development packages allows for automation that is not necessarily practical when users are putting their dependencies in their home directory on a case-by-case basis. Nevertheless, the benefits of allowing parallel development package installations is perhaps not something that a lot of people want to take advantage of. The real point, however, is that the spec file I posted is that a system-wide installation would use the same conventions as the one that a user puts in his or her home directory. I am used to using Boost in this way, and thus it is my desire to see these conventions used in a system-wide installation. Perhaps my uses of Boost are atypical, but I like using the fully qualified names. Another important aspect of the spec file that I posted is that it does not strip out the multi-threaded versions of the Boost libraries. That, IMO, is a very detrimental aspect of the way that Red Hat has been packaging Boost.
Relative to the Boost RPM distributed for use on Red Hat distributions of Linux (I do not have experience with pre-packaged versions of Boost from other Linux distribution vendors, so I cannot comment on how they do things), this RPM spec file has the following benefits:
* Allows parallel installations of multiple Boost releases (both the run-time RPM and the developer RPM) * Installs single- and multi-threaded builds of libraries
The spec file that Red Hat uses for building Boost RPMs removes the toolset name and the version information from the base name of the library, and it only installs the single-threaded build of each library. For reasons that are not yet clear to me, an additional symlink is created for each Boost shared library named libboost_<libname>.so.2 that points to libboost_<libname>.so.1.33.1.
I guess this is meant to address the "broken promise" problem: if boost.so.1.33 were not fully ABI compatible with boost.so.1.32, it was necessary to label boost.so.1.33 with a SONAME of boost.so.2 so that applications linked against boost.so.1.32 would not attempt to load it and crash. By the way, this leads me to think (I have not checked) that the packages are either (a) already *are* installable side by side, if the SONAME is different, or (b) must be prevented from being available at the same time, if the SONAME is the same.
Yes, the non-development Boost packages from Red Hat are installable in parallel. What I failed to make clear the in text quoted above is that the spec file that I posted allows for both the run-time RPM and the development RPM to be installed in parallel whereas the Red Hat approach only allows multiple versions of the run-time RPM to be installed in parallel.
This prevents multiple parallel run-time installations. Multiple developer installations are prevented by the removal of the version information from the base library name and by the fact that the headers are placed in /usr/include/boost instead of in /usr/include/boost-1_33_1/boost.
If multiple developer installations exist, where does the development symlink point to ? More to the point: if it does not point to the library provided by Red Hat, I am in trouble.
The links installed by -devel-symlink would point to the version that corresponds with their release. The intention with both of the -symlink packages is to provide compatibility with the way that Red Hat has been doing things thus far, so it should look the same as the way that Red Hat installs Boost in terms of compiler and linker options.
The second RPM installs unversioned symbolic links to the fully qualified library names and to the Boost header directory. The idea here is that users could have multiple Boost developer installations in parallel, and if they so desired, they could install this extra RPM with unversioned names to point to whichever Boost installation should be the "default" version. Since the symlinks are unversioned, parallel installations of multiple versions of these RPMs is not possible. Nevertheless, the two together provide a means to make a Boost RPM installation that is compatible with what Red Hat has been distributing for quite a while now.
Did you consider contacting the people at Red Hat managing the packaging of Boost ?
We did contact them a little over a year ago about the fact that the multi-threaded versions of the Boost libraries are being stripped from the installation, and we were told that they were not interested in our changes to address that. It is worth trying again to get them to include the multi-threaded libraries. That specific aspect is highly critical for us.
It might be just me, but the above is ... uncustomary.
It is not uncommon for open source software to include a spec file so that people downloading it can use package management for handling the build, installation, and upgrade processes. Whether any given Linux distributor uses a pre-existing spec file as a starting point for their own repackaging of said software is up to them.
Are you trying to follow standard shared library versioning, or do you mean to handcraft what libtool does ?
I mean to follow what Boost does currently because I like that approach. That's just my personal preference, though, and I admit that it took some getting used to when it was first introduced. In particular, I like that the Boost library naming convention is standard across platforms since I regularly switch between three or four operating systems in any given day. Another software tool that I use (that shall remain nameless) uses a different library naming convention between Linux/BSD/Solaris, Mac OS X, and Windows. While symlinks address the Mac OS X differences, my builds have to account for the different usage of the version number in the Windows case. To me, that means extra work and an extra point of failure that doesn't exist for Boost because the build can handle Boost identically on all platforms (assuming proper management of the toolset name differences). -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
This discussion sort of fizzled out a couple of weeks back, so I thought that I would post a short summary to clarify the goals of the RPM spec file that I posted. First, here is how things are with the way that Red Hat distributes builds of Boost: * Allows parallel installations of versioned Boost shared libraries so that boost-1.32.0.rpm, boost-1.33.1.rpm, etc. could all be installed side by side * Does not install multi-threaded variants of Boost libraries * Does not install debug versions of libraries * Does not put headers in a versioned subdirectory of /usr/include * Strips toolset and version from the base library name (libboost_signals.so versus libboost_signals-gcc-1_33_1.so) * Does not allow multiple boost-devel RPMs to be installed in parallel The spec file that I posted does the following: * Allows parallel installations of versioned Boost shared libraries so that boost-1.32.0.rpm, boost-1.33.1.rpm, etc. could all be installed side by side * Installs multi-threaded variants of Boost libraries * Installs both debug and optimized versions of all libraries * Puts headers in a versioned subdirectory of /usr/include * Uses fully qualified library names * Allows multiple boost-devel RPMs to be installed in parallel * Provides compatibility with (current) Red Hat conventions using optional "-symlink" packages, the use of which would conflict with Boost RPMs provided by Red Hat and would prevent the ability to install multiple boost-devel RPMs in parallel Basically, the spec file that I posted follows what I understand to be the "normal" way of installing Boost. In other words, the boost and boost-devel RPMs created by this spec file provide a Boost installation as it would look after running 'bjam install --prefix=/usr'. Are there other thoughts on this topic other than what was discussed previously on this thread (much of which is below), or is this approach to installing Boost not how people normally want to operate on Linux? -Patrick Patrick Hartling wrote:
Davide Bolcioni wrote:
Patrick Hartling wrote:
The philosophy behind this new spec file is to be as true as possible to what I understand to be a "normal" Boost installation. I realize that users are afforded many ways to customize their Boost installation through different build-time options. Without doing any build customization, however, a Boost installation has single- and multi-threaded variants of libraries, both static and dynamic, that are named based on the toolset used for building and the Boost version number. Furthermore, the headers are installed in a versioned subdirectory. All of this allows parallel installations of different Boost build variants, and I see that as an extremely powerful capability. I am mostly a lurker on the Boost list, but the above strikes me as odd.
The point of installing a library as an RPM package is to satisfy the dependencies for other installed packages, not to make it available to a software developer. Similarly, the corresponding development package is intended to facilitate the packaging by making sure that the source code gets compiled against the same set of choices which are embedded in the RPM package found on the destination host, so that saying "Requires: boost" in the .spec file has a good chance of working.
Software developers can readily install multiple versions in their home directories, or even dedicate seperate accounts to separate versions, so I am not seeing the benefit of the above (except for developers using RPM to manage software in their home directory: an interesting thought).
You are right, this is possible. Using package management to deploy development packages allows for automation that is not necessarily practical when users are putting their dependencies in their home directory on a case-by-case basis. Nevertheless, the benefits of allowing parallel development package installations is perhaps not something that a lot of people want to take advantage of. The real point, however, is that the spec file I posted is that a system-wide installation would use the same conventions as the one that a user puts in his or her home directory. I am used to using Boost in this way, and thus it is my desire to see these conventions used in a system-wide installation. Perhaps my uses of Boost are atypical, but I like using the fully qualified names.
Another important aspect of the spec file that I posted is that it does not strip out the multi-threaded versions of the Boost libraries. That, IMO, is a very detrimental aspect of the way that Red Hat has been packaging Boost.
Relative to the Boost RPM distributed for use on Red Hat distributions of Linux (I do not have experience with pre-packaged versions of Boost from other Linux distribution vendors, so I cannot comment on how they do things), this RPM spec file has the following benefits:
* Allows parallel installations of multiple Boost releases (both the run-time RPM and the developer RPM) * Installs single- and multi-threaded builds of libraries
The spec file that Red Hat uses for building Boost RPMs removes the toolset name and the version information from the base name of the library, and it only installs the single-threaded build of each library. For reasons that are not yet clear to me, an additional symlink is created for each Boost shared library named libboost_<libname>.so.2 that points to libboost_<libname>.so.1.33.1. I guess this is meant to address the "broken promise" problem: if boost.so.1.33 were not fully ABI compatible with boost.so.1.32, it was necessary to label boost.so.1.33 with a SONAME of boost.so.2 so that applications linked against boost.so.1.32 would not attempt to load it and crash. By the way, this leads me to think (I have not checked) that the packages are either (a) already *are* installable side by side, if the SONAME is different, or (b) must be prevented from being available at the same time, if the SONAME is the same.
Yes, the non-development Boost packages from Red Hat are installable in parallel. What I failed to make clear the in text quoted above is that the spec file that I posted allows for both the run-time RPM and the development RPM to be installed in parallel whereas the Red Hat approach only allows multiple versions of the run-time RPM to be installed in parallel.
This prevents multiple parallel run-time installations. Multiple developer installations are prevented by the removal of the version information from the base library name and by the fact that the headers are placed in /usr/include/boost instead of in /usr/include/boost-1_33_1/boost. If multiple developer installations exist, where does the development symlink point to ? More to the point: if it does not point to the library provided by Red Hat, I am in trouble.
The links installed by -devel-symlink would point to the version that corresponds with their release. The intention with both of the -symlink packages is to provide compatibility with the way that Red Hat has been doing things thus far, so it should look the same as the way that Red Hat installs Boost in terms of compiler and linker options.
The second RPM installs unversioned symbolic links to the fully qualified library names and to the Boost header directory. The idea here is that users could have multiple Boost developer installations in parallel, and if they so desired, they could install this extra RPM with unversioned names to point to whichever Boost installation should be the "default" version. Since the symlinks are unversioned, parallel installations of multiple versions of these RPMs is not possible. Nevertheless, the two together provide a means to make a Boost RPM installation that is compatible with what Red Hat has been distributing for quite a while now. Did you consider contacting the people at Red Hat managing the packaging of Boost ?
We did contact them a little over a year ago about the fact that the multi-threaded versions of the Boost libraries are being stripped from the installation, and we were told that they were not interested in our changes to address that. It is worth trying again to get them to include the multi-threaded libraries. That specific aspect is highly critical for us.
It might be just me, but the above is ... uncustomary.
It is not uncommon for open source software to include a spec file so that people downloading it can use package management for handling the build, installation, and upgrade processes. Whether any given Linux distributor uses a pre-existing spec file as a starting point for their own repackaging of said software is up to them.
Are you trying to follow standard shared library versioning, or do you mean to handcraft what libtool does ?
I mean to follow what Boost does currently because I like that approach. That's just my personal preference, though, and I admit that it took some getting used to when it was first introduced. In particular, I like that the Boost library naming convention is standard across platforms since I regularly switch between three or four operating systems in any given day.
Another software tool that I use (that shall remain nameless) uses a different library naming convention between Linux/BSD/Solaris, Mac OS X, and Windows. While symlinks address the Mac OS X differences, my builds have to account for the different usage of the version number in the Windows case. To me, that means extra work and an extra point of failure that doesn't exist for Boost because the build can handle Boost identically on all platforms (assuming proper management of the toolset name differences).
-- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
Patrick Hartling wrote:
This discussion sort of fizzled out a couple of weeks back, so I thought that I would post a short summary to clarify the goals of the RPM spec file that I posted. First, here is how things are with the way that Red Hat distributes builds of Boost:
* Allows parallel installations of versioned Boost shared libraries so that boost-1.32.0.rpm, boost-1.33.1.rpm, etc. could all be installed side by side * Does not install multi-threaded variants of Boost libraries * Does not install debug versions of libraries * Does not put headers in a versioned subdirectory of /usr/include * Strips toolset and version from the base library name (libboost_signals.so versus libboost_signals-gcc-1_33_1.so) * Does not allow multiple boost-devel RPMs to be installed in parallel
The spec file that I posted does the following:
* Allows parallel installations of versioned Boost shared libraries so that boost-1.32.0.rpm, boost-1.33.1.rpm, etc. could all be installed side by side * Installs multi-threaded variants of Boost libraries * Installs both debug and optimized versions of all libraries * Puts headers in a versioned subdirectory of /usr/include * Uses fully qualified library names * Allows multiple boost-devel RPMs to be installed in parallel * Provides compatibility with (current) Red Hat conventions using optional "-symlink" packages, the use of which would conflict with Boost RPMs provided by Red Hat and would prevent the ability to install multiple boost-devel RPMs in parallel
I see 2 issues with the proposed spec. 1) It would install into %{_libdir}, and so potentially conflict with redhat's rpms. I recommend using a different directory. We have /etc/ld.so.conf.d, so this is easy to implement. 2) Unless you fix #1, ldconfig would put libboost_signals.so as a link to redhat's version (because of libboost_signals.so.2).
Neal Becker wrote:
Patrick Hartling wrote:
This discussion sort of fizzled out a couple of weeks back, so I thought that I would post a short summary to clarify the goals of the RPM spec file that I posted. First, here is how things are with the way that Red Hat distributes builds of Boost:
* Allows parallel installations of versioned Boost shared libraries so that boost-1.32.0.rpm, boost-1.33.1.rpm, etc. could all be installed side by side * Does not install multi-threaded variants of Boost libraries * Does not install debug versions of libraries * Does not put headers in a versioned subdirectory of /usr/include * Strips toolset and version from the base library name (libboost_signals.so versus libboost_signals-gcc-1_33_1.so) * Does not allow multiple boost-devel RPMs to be installed in parallel
The spec file that I posted does the following:
* Allows parallel installations of versioned Boost shared libraries so that boost-1.32.0.rpm, boost-1.33.1.rpm, etc. could all be installed side by side * Installs multi-threaded variants of Boost libraries * Installs both debug and optimized versions of all libraries * Puts headers in a versioned subdirectory of /usr/include * Uses fully qualified library names * Allows multiple boost-devel RPMs to be installed in parallel * Provides compatibility with (current) Red Hat conventions using optional "-symlink" packages, the use of which would conflict with Boost RPMs provided by Red Hat and would prevent the ability to install multiple boost-devel RPMs in parallel
I see 2 issues with the proposed spec.
1) It would install into %{_libdir}, and so potentially conflict with redhat's rpms.
The boost and boost-devel RPMs made by this spec file do not currently conflict with those made by Red Hat. However, if Red Hat were to start using fully qualified names on the static and shared libraries, then there would be a conflict. My main goal with posting this RPM spec file to this list is for it (or something similar to it) to become the "upstream" spec file for Boost in hopes that Red Hat and other Linux vendors would follow these conventions for future releases. Hence, a conflict would, IMHO, be a good thing in this case. The "-symlink" packages do conflict with the way that Red Hat currently packages Boost, and that is why they are optional. The intention is to provide a way to have a replacement Boost installation that looks like how Red Hat currently does things--a "just in case" sort of thing to avoid breaking existing software that is linked against the libraries built by Red Hat.
I recommend using a different directory. We have /etc/ld.so.conf.d, so this is easy to implement.
With all due respect, I must admit that I do not like this idea, and that is why I have not pursued even though you have recommended it previously. Doing it this way means that people building against Boost have to know to put -L/usr/lib/xxx in their link line because the Boost libraries in the obvious place are the "wrong" libraries. For run-time purposes, though, this approach would be fine. -Patrick
2) Unless you fix #1, ldconfig would put libboost_signals.so as a link to redhat's version (because of libboost_signals.so.2).
-- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
Patrick Hartling wrote:
The spec file that I posted does the following:
* Allows parallel installations of versioned Boost shared libraries so that boost-1.32.0.rpm, boost-1.33.1.rpm, etc. could all be installed side by side * Installs multi-threaded variants of Boost libraries * Installs both debug and optimized versions of all libraries * Puts headers in a versioned subdirectory of /usr/include * Uses fully qualified library names * Allows multiple boost-devel RPMs to be installed in parallel
OK.
* Provides compatibility with (current) Red Hat conventions using optional "-symlink" packages, the use of which would conflict with Boost RPMs provided by Red Hat and would prevent the ability to install multiple boost-devel RPMs in parallel
Are those different from the synlinks the "bjam install" does? Does your RPM put in the symlinks "bjam install" produces?
Basically, the spec file that I posted follows what I understand to be the "normal" way of installing Boost. In other words, the boost and boost-devel RPMs created by this spec file provide a Boost installation as it would look after running 'bjam install --prefix=/usr'.
Are there other thoughts on this topic other than what was discussed previously on this thread (much of which is below), or is this approach to installing Boost not how people normally want to operate on Linux?
I personally like it, but then again I came up with the current install scheme, so I'm biased :-) A few future and integration questions... Have you tried packaging the 1.34 branch? Is it buildable if one doesn't have admin privileges? I'm asking because making the RPM during a release cycle would be much easier if we can use the SF compile farm machines instead of relying on personal setups. It's been suggested a few times that we should move Boost towards a non-monolithic distribution model. Which means that we would want to have individual RPMs for the various libraries. Which I guess also means that a top level Boost RPM would be only a reference to the other version specific RPMs for the libraries. Now... Do you see any problems that your RPM would create if we do move in that direction? If Boost does provide an RPM, we would need someone to actively maintain it. Are you volunteering yourself to do this maintenance? Note, it would not just be editing the RPM script(s) but also witting documentation, specifically for the release manager to use in building the RPMs. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
I know I'm quoting most of the original message... But this is a ping. Patrick you there? Rene Rivera was being inquisitive:
Patrick Hartling wrote:
The spec file that I posted does the following:
* Provides compatibility with (current) Red Hat conventions using optional "-symlink" packages, the use of which would conflict with Boost RPMs provided by Red Hat and would prevent the ability to install multiple boost-devel RPMs in parallel
Are those different from the synlinks the "bjam install" does? Does your RPM put in the symlinks "bjam install" produces?
Basically, the spec file that I posted follows what I understand to be the "normal" way of installing Boost. In other words, the boost and boost-devel RPMs created by this spec file provide a Boost installation as it would look after running 'bjam install --prefix=/usr'.
Are there other thoughts on this topic other than what was discussed previously on this thread (much of which is below), or is this approach to installing Boost not how people normally want to operate on Linux?
I personally like it, but then again I came up with the current install scheme, so I'm biased :-) A few future and integration questions...
Have you tried packaging the 1.34 branch?
Is it buildable if one doesn't have admin privileges? I'm asking because making the RPM during a release cycle would be much easier if we can use the SF compile farm machines instead of relying on personal setups.
It's been suggested a few times that we should move Boost towards a non-monolithic distribution model. Which means that we would want to have individual RPMs for the various libraries. Which I guess also means that a top level Boost RPM would be only a reference to the other version specific RPMs for the libraries. Now...
Do you see any problems that your RPM would create if we do move in that direction?
If Boost does provide an RPM, we would need someone to actively maintain it. Are you volunteering yourself to do this maintenance? Note, it would not just be editing the RPM script(s) but also witting documentation, specifically for the release manager to use in building the RPMs.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
I know I'm quoting most of the original message... But this is a ping. Patrick you there?
Oops, I completely dropped the ball on this. Thanks for the ping. See my responses below.
Rene Rivera was being inquisitive:
Patrick Hartling wrote:
The spec file that I posted does the following:
* Provides compatibility with (current) Red Hat conventions using optional "-symlink" packages, the use of which would conflict with Boost RPMs provided by Red Hat and would prevent the ability to install multiple boost-devel RPMs in parallel Are those different from the synlinks the "bjam install" does?
Yes. The boost and boost-devel RPMs that get created are intended to look just like the results of "bjam install". The additional boost-symlinks and boost-devel-symlinks are add ons (more or less) intended to make the installation appear as it does now with the RPM distributed by Red Hat.
Does your RPM put in the symlinks "bjam install" produces?
Yes.
Basically, the spec file that I posted follows what I understand to be the "normal" way of installing Boost. In other words, the boost and boost-devel RPMs created by this spec file provide a Boost installation as it would look after running 'bjam install --prefix=/usr'.
Are there other thoughts on this topic other than what was discussed previously on this thread (much of which is below), or is this approach to installing Boost not how people normally want to operate on Linux? I personally like it, but then again I came up with the current install scheme, so I'm biased :-) A few future and integration questions...
Have you tried packaging the 1.34 branch?
No, not yet. I can give it a try.
Is it buildable if one doesn't have admin privileges? I'm asking because making the RPM during a release cycle would be much easier if we can use the SF compile farm machines instead of relying on personal setups.
Yes, you just have to have a ~/.rpmmacros file that sets %_topdir to a tree where you have write access. Mine looks like this: %_topdir /home/patrick/rpm Under rpm, there are the directories BUILD, RPMS, SOURCES, SPECS, and SRPMS. I put my .spec file in rpm/SPECS and the Boost source in rpm/SOURCES and run 'rpmbuild -ba boost.spec'.
It's been suggested a few times that we should move Boost towards a non-monolithic distribution model. Which means that we would want to have individual RPMs for the various libraries. Which I guess also means that a top level Boost RPM would be only a reference to the other version specific RPMs for the libraries. Now...
Do you see any problems that your RPM would create if we do move in that direction?
Not strictly, but I don't have experience with making a top-level RPM as you have described. It wouldn't be too much work to make a bunch of subpackages within the boost.spec file that I posted. I have already done that for another project. It makes the spec file more complicated, but having a monolithic RPM for this particular software didn't make sense. What could get complicated is dealing with optional libraries and the like. In my experience, it can get tricky to put conditional stuff into a spec file, mainly because rpmbuild needs to know which sub-packages to handle after the build completes and which ones to skip. If that can't be determined statically when rpmbuild gets started (before any source extraction or build takes place), then I don't know how to handle that case. That doesn't mean that it's impossible, and I am quite new to writing RPM spec files. Others may have insight into this sort of situation.
If Boost does provide an RPM, we would need someone to actively maintain it. Are you volunteering yourself to do this maintenance?
Yes.
Note, it would not just be editing the RPM script(s) but also witting documentation, specifically for the release manager to use in building the RPMs.
No problem. I've written a lot of documentation, and believe it or not, I normally enjoy doing so. :) -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
Patrick Hartling escreveu:
What could get complicated is dealing with optional libraries and the like. In my experience, it can get tricky to put conditional stuff into a spec file, mainly because rpmbuild needs to know which sub-packages to handle after the build completes and which ones to skip. If that can't be determined statically when rpmbuild gets started (before any source extraction or build takes place), then I don't know how to handle that case. That doesn't mean that it's impossible, and I am quite new to writing RPM spec files. Others may have insight into this sort of situation.
The point of a non-monolithic set of RPM files is not to conditionally build packages, but to conditionally install them. This enables other packages to describe their dependencies in a more granular way. Suppose someone wants to install a new cron substitute based on DateTime. This person doesn't care about Boost. It's ideal for her to install only DateTime, and keep things to a minimum. Typically, pre-built packages will live in a repository somewhere, available to interested people that should be installing them through some package dependency resolver like yum or apt. The particular complication in this case is determining the inter-dependencies in the Boost collection. It may be that the goodness of the non-monolithic design will be made nil by the extreme interconnection of all the libraries. I can't tell. -- Pedro Lamarão
Pedro Lamarão wrote:
Patrick Hartling escreveu:
What could get complicated is dealing with optional libraries and the like. In my experience, it can get tricky to put conditional stuff into a spec file, mainly because rpmbuild needs to know which sub-packages to handle after the build completes and which ones to skip. If that can't be determined statically when rpmbuild gets started (before any source extraction or build takes place), then I don't know how to handle that case. That doesn't mean that it's impossible, and I am quite new to writing RPM spec files. Others may have insight into this sort of situation.
The point of a non-monolithic set of RPM files is not to conditionally build packages, but to conditionally install them.
I understand that, but the RPM spec file has to know what packages to create and what files go in those packages. The rpmbuild command will fail if there are unpackaged files or if an attempt is made to include a non-existent file (in other words, a shared library that didn't get built for whatever reason) in a package. Hence, it is critical for the RPM spec file to know what is being compiled and what isn't. One way of handling this would be to have a spec file for each library instead of having one that builds everything at once and then packages things up into multiple .rpm files.
This enables other packages to describe their dependencies in a more granular way. Suppose someone wants to install a new cron substitute based on DateTime. This person doesn't care about Boost. It's ideal for her to install only DateTime, and keep things to a minimum.
Yes, and I would be happy to see Boost packaged up this way.
Typically, pre-built packages will live in a repository somewhere, available to interested people that should be installing them through some package dependency resolver like yum or apt.
Right.
The particular complication in this case is determining the inter-dependencies in the Boost collection. It may be that the goodness of the non-monolithic design will be made nil by the extreme interconnection of all the libraries. I can't tell.
I have no idea, but it would definitely be interesting to see how that pans out. How would header files not associated with a compiled library be packaged? Would there be a boost-base package, or would the header-only libraries need to be partitioned up, too? -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
I'd just like to mention that I know am a fedora-extras contributor. If we could design a package that would not cause a conflict with the existing fedora rpm I could try to get it added.
Pedro Lamarão <pedro.lamarao@intersix.com.br> writes:
The particular complication in this case is determining the inter-dependencies in the Boost collection. It may be that the goodness of the non-monolithic design will be made nil by the extreme interconnection of all the libraries. I can't tell.
They are not strongly coupled to one another in that way. Boost as a whole ends up being fairly nicely layered and parts are separable. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Greetings, just my 2 cents ... Patrick Hartling wrote:
* Installs multi-threaded variants of Boost libraries * Installs both debug and optimized versions of all libraries
I guess linking an executable built against the multi-threaded library with a .so built against the single-threaded library is somehow detected ?
* Allows multiple boost-devel RPMs to be installed in parallel
I see this as somewhat dangerous. Consider this bug: http://lists.debian.org/debian-devel/2005/09/msg00657.html which occurred because code linked against libstdc++5 linked another library which was itself linked against libstdc++6, throwing any ODR assumptions by either compiler into la-la land. Although stuff such as linker namespaces and visibility are meant to address that, they introduce platform- and linker-specific magic which should be weighted against the simple approach: an executable and all its libraries, recursively, constitute a single process image so everything must be built against the exact same set of headers and libraries. Now, having a development environment where exactly one development package can be installed helps with the above simple approach: just rebuild all .src.rpms in this development environment. If you have to build for multiple targets, look into chroots, virtual machines, or stuff like mock http://fedoraproject.org/wiki/Legacy/Mock instead of relying on developers getting it manually correct every single time (OK, in their Makefiles). Having the development package chosen once, by the distributor when the distribution is first released, also helps different developers to agree on which development package to use.
Basically, the spec file that I posted follows what I understand to be the "normal" way of installing Boost. In other words, the boost and boost-devel RPMs created by this spec file provide a Boost installation as it would look after running 'bjam install --prefix=/usr'.
This is fine for a single developer in his $HOME, but I am unconvinced of its merits in a production system under package management. Thank your for your consideration, Davide Bolcioni -- There is no place like /home.
Davide Bolcioni wrote:
Greetings, just my 2 cents ...
Patrick Hartling wrote:
* Installs multi-threaded variants of Boost libraries * Installs both debug and optimized versions of all libraries
I guess linking an executable built against the multi-threaded library with a .so built against the single-threaded library is somehow detected ?
* Allows multiple boost-devel RPMs to be installed in parallel
I see this as somewhat dangerous. Consider this bug:
http://lists.debian.org/debian-devel/2005/09/msg00657.html
which occurred because code linked against libstdc++5 linked another library which was itself linked against libstdc++6, throwing any ODR assumptions by either compiler into la-la land. Although stuff such as linker namespaces and visibility are meant to address that, they introduce platform- and linker-specific magic which should be weighted against the simple approach: an executable and all its libraries, recursively, constitute a single process image so everything must be built against the exact same set of headers and libraries.
I agree with this philosophy, and the bug pointed out here is something that I have run into more than once myself. I tracked FreeBSD-current for many years, and any time there was a shared library version bump on libc, libm, or anything else in /lib or /usr/lib, it meant rebuilding everything in /usr/local to ensure that all code built thereafter was linked against the same set of libraries. Using binary-only software from a commercial vendor usually meant installing a compatibility package for the last stable release (compat4x for running 5-current for example) which someone had to maintain. My point is that, while none of this was pretty or fun, I just accepted keeping shared libraries in order as a fact of life in the world of software development.
Now, having a development environment where exactly one development package can be installed helps with the above simple approach: just rebuild all .src.rpms in this development environment. If you have to build for multiple targets, look into chroots, virtual machines, or stuff like mock
http://fedoraproject.org/wiki/Legacy/Mock
instead of relying on developers getting it manually correct every single time (OK, in their Makefiles). Having the development package chosen once, by the distributor when the distribution is first released, also helps different developers to agree on which development package to use.
Thanks for the pointer to an interesting tool. It definitely looks like something that could come in very handy.
Basically, the spec file that I posted follows what I understand to be the "normal" way of installing Boost. In other words, the boost and boost-devel RPMs created by this spec file provide a Boost installation as it would look after running 'bjam install --prefix=/usr'.
This is fine for a single developer in his $HOME, but I am unconvinced of its merits in a production system under package management.
You make many good points here, but I am unconvinced that people should be disallowed from installing parallel boost-devel packages just because someone might make a mistake. I'd rather give people the option to do it and let them decide whether it is worth using than prevent it altogether. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
On 8/15/06, Patrick Hartling <patrick@137.org> wrote:
Davide Bolcioni wrote:
Patrick Hartling wrote:
The point of installing a library as an RPM package is to satisfy the dependencies for other installed packages, not to make it available to a software developer. Similarly, the corresponding development package is intended to facilitate the packaging by making sure that the source code gets compiled against the same set of choices which are embedded in the RPM package found on the destination host, so that saying "Requires: boost" in the .spec file has a good chance of working.
[snipped]
You are right, this is possible. Using package management to deploy development packages allows for automation that is not necessarily practical when users are putting their dependencies in their home directory on a case-by-case basis. Nevertheless, the benefits of allowing parallel development package installations is perhaps not something that a lot of people want to take advantage of. The real point, however, is that the spec file I posted is that a system-wide installation would use the same conventions as the one that a user puts in his or her home directory. I am used to using Boost in this way, and thus it is my desire to see these conventions used in a system-wide installation. Perhaps my uses of Boost are atypical, but I like using the fully qualified names.
I do not use RedHat based systems much and have a few reservations against the RPM approach for packaging -- I am a Debian fan needless to say, but I digress. As for installing RPM's to satisfy dependencies, that's just one of the main reasons why you'll want to build a package for a development library (like boost, ACE, <insert other C++ library here>). Another reason why you'll want RPM's or "packages" in general is to standardize more or less the build environment that you are working in. In cases where you have different applications building on the same machine using the same compiler set and libraries, you'd want all the applications to expect the existence of not only the dependencies (when you're making packages out of the applications yourself) but also of a package that can be pulled and installed when that dependency is not met. In these cases where you have a "build server" and maybe a "continuous integration environment" on different (hardware) platforms/architectures and distributions (rpm based, deb based, and even maybe Gentoo-like build everything), you want to be able to standardize on the most common installations possible. Having a package that's made available to the whole system or installed as part of the (Linux) distribution is definitely a step in the right direction especially for organizations/enterprises/people who want to make packages out of the applications they are building. In our case, we use Debian and we write a set of applications that are made to work with the stable banch -- we build the Boost 1.33.1 library and package it as a .deb so that we can install the binary libraries on the stable branch (which is pretty much like backporting, but we already include Asio and Spirit in the custom Boost .deb we build). I would imagine (and would like to think) that people who develop for RedHat based systems would want to be able to roll their own binary Boost .rpm's for distribution along with their applications also distributed as .rpm's. I agree with David on this one, and will look forward to a Boost provided SPEC file without having to rely on the configurations of RedHat/Fedora of the Boost library. Hope this helps! -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
Dean Michael Berris wrote:
On 8/15/06, Patrick Hartling <patrick@137.org> wrote:
Davide Bolcioni wrote:
Patrick Hartling wrote:
The point of installing a library as an RPM package is to satisfy the dependencies for other installed packages, not to make it available to a software developer. Similarly, the corresponding development package is intended to facilitate the packaging by making sure that the source code gets compiled against the same set of choices which are embedded in the RPM package found on the destination host, so that saying "Requires: boost" in the .spec file has a good chance of working.
[snipped] You are right, this is possible. Using package management to deploy development packages allows for automation that is not necessarily practical when users are putting their dependencies in their home directory on a case-by-case basis. Nevertheless, the benefits of allowing parallel development package installations is perhaps not something that a lot of people want to take advantage of. The real point, however, is that the spec file I posted is that a system-wide installation would use the same conventions as the one that a user puts in his or her home directory. I am used to using Boost in this way, and thus it is my desire to see these conventions used in a system-wide installation. Perhaps my uses of Boost are atypical, but I like using the fully qualified names.
I do not use RedHat based systems much and have a few reservations against the RPM approach for packaging -- I am a Debian fan needless to say, but I digress.
I have nothing against Debian or any other Linux distribution (since I'd rather be using BSD anyway). It's just that, at the moment, I only know how to make RPMs (and installers for Windows and Mac OS X). :)
As for installing RPM's to satisfy dependencies, that's just one of the main reasons why you'll want to build a package for a development library (like boost, ACE, <insert other C++ library here>). Another reason why you'll want RPM's or "packages" in general is to standardize more or less the build environment that you are working in.
I agree.
In cases where you have different applications building on the same machine using the same compiler set and libraries, you'd want all the applications to expect the existence of not only the dependencies (when you're making packages out of the applications yourself) but also of a package that can be pulled and installed when that dependency is not met. In these cases where you have a "build server" and maybe a "continuous integration environment" on different (hardware) platforms/architectures and distributions (rpm based, deb based, and even maybe Gentoo-like build everything), you want to be able to standardize on the most common installations possible.
Definitely.
Having a package that's made available to the whole system or installed as part of the (Linux) distribution is definitely a step in the right direction especially for organizations/enterprises/people who want to make packages out of the applications they are building. In our case, we use Debian and we write a set of applications that are made to work with the stable banch -- we build the Boost 1.33.1 library and package it as a .deb so that we can install the binary libraries on the stable branch (which is pretty much like backporting, but we already include Asio and Spirit in the custom Boost .deb we build).
Is your packaging of Boost into a .deb package available somewhere? Or do you have recommendations on how to do it? I would like to learn more about Debian packaging, and it would be very helpful to have something I could compare to what we have been doing for Boost.
I would imagine (and would like to think) that people who develop for RedHat based systems would want to be able to roll their own binary Boost .rpm's for distribution along with their applications also distributed as .rpm's.
That is what we are doing currently, but we run into problems because our packaging of Boost is different than what Red Hat is doing. My intention with this spec file is to have it (or something similar) be included with Boost so that it is easier for people to do exactly what you are describing.
I agree with David on this one, and will look forward to a Boost provided SPEC file without having to rely on the configurations of RedHat/Fedora of the Boost library.
Hope this helps!
Maybe I am misunderstanding, but I think that you inverted the quoting above. It appears to me that you attributed David's argument to me and vice versa. It seems to me that you and I share a lot of goals WRT software deployment and maintenance. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
On 9/9/06, Patrick Hartling <patrick@137.org> wrote:
Having a package that's made available to the whole system or installed as part of the (Linux) distribution is definitely a step in the right direction especially for organizations/enterprises/people who want to make packages out of the applications they are building. In our case, we use Debian and we write a set of applications that are made to work with the stable banch -- we build the Boost 1.33.1 library and package it as a .deb so that we can install the binary libraries on the stable branch (which is pretty much like backporting, but we already include Asio and Spirit in the custom Boost .deb we build).
Is your packaging of Boost into a .deb package available somewhere? Or do you have recommendations on how to do it? I would like to learn more about Debian packaging, and it would be very helpful to have something I could compare to what we have been doing for Boost.
The packaging of the Boost 1.33.1 + Boost.Asio 0.3.7 + Boost.Spirit 1.8.3 we're using for our current project is not _yet_ available from the Internet. For the matter, it might take a while before we can get out a .deb out for the Debian stable banch, because the packages in that branch undergo a process. We like testing things out before releasing anything. ;) I could certainly ask the package maintainer in our team to write it down and maybe put it up in the Boost Wiki. That might take some time, but I believe he just made a few modifications to that already included debian packaging instructions/files in the Boost 1.33.1 downloadable package. You can look at how to do the debian package making in the debian site: http://debian.org/ -- I'm currently too lazy to look for the link to the actual documents. While you're at it, you might also want to try Debian out. :)
I would imagine (and would like to think) that people who develop for RedHat based systems would want to be able to roll their own binary Boost .rpm's for distribution along with their applications also distributed as .rpm's.
That is what we are doing currently, but we run into problems because our packaging of Boost is different than what Red Hat is doing. My intention with this spec file is to have it (or something similar) be included with Boost so that it is easier for people to do exactly what you are describing.
I understand your pain... I had been disappointed that the Boost 1.33 release has not yet been accepted into the Debian stable tree -- which would have made our lives a lot easier. IIRC, Boost 1.30 is the one available from the stable branch and I am more familiar with the 1.33 libraries. That being said, I'm also lucky that I have an experienced Debian and Ubuntu package maintainer in my team. ;)
I agree with David on this one, and will look forward to a Boost provided SPEC file without having to rely on the configurations of RedHat/Fedora of the Boost library.
Hope this helps!
Maybe I am misunderstanding, but I think that you inverted the quoting above. It appears to me that you attributed David's argument to me and vice versa. It seems to me that you and I share a lot of goals WRT software deployment and maintenance.
Yes, my bad. I meant I agree with you. :D -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com
participants (9)
-
David Abrahams -
Davide Bolcioni -
Dean Michael Berris -
John Maddock -
Neal Becker -
Patrick Hartling -
Pedro Lamarão -
Philipp Thomas -
Rene Rivera