On Tue, Dec 27, 2011 at 11:28:14AM +0100, Thomas Krennwallner wrote: > As long as something depends on 1.46, I assume that it should be > around. The current situation is sub-optimal, because almost everything > depends on the non-versioned boost libs of boost-defaults, despite > boost's tendency to break packages when switching to a new version.
In fairness, boost doesn't break everything on each release, though it
often feels like it :-). One issue with boost is that it is really a
conglomeration of several dozen libraries, some of which are quite
stable. Others are less so, sometimes by intention, sometimes
inadvertently.
The other big issue with boost is they have an agressive release
schedule of 4 times/year.
> The question is, which strategy is better?
>
> (1) Clearly record the dependencies in packages that depend on boost,
> i.e., Build-Depends on libboost-foo1.46-dev instead of
> libboost-foo-dev, or
> (2) let boost-defaults decide which version of boost is the currently
> stable boost.
>
> IMHO (2) just hides FTBSes of the packages.
I will offer a third strategy:
(3) Offer boost-defaults for: advanced users, for packages that
generally stick to the stable parts of boost, for packages that
or have upstream authors that track the latest boost.
Other packages can build to versioned boost dev packages known
to work.
Due to the frequent boost releases, there is a large cost to using the
versioned dependencies, so I encourage using the non-versioned
packages when possible. This is an evolving process and I think we're
still learning which category a given package might fall into. So
it's not a surprise that some adjustments are necessary with each
boost release.
And, of course, there are the standard number of bugs in a given boost
release so even if "unversioned devs" is the right strategy for a
given package, a new boost may still break it until a boost bug is
fixed.
Regards,
-Steve
signature.asc
Description: Digital signature
