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