Bug#749944: build ogre-1.9 against new boost-defaults 1.55?

[Scott Howard]

reopen 749944

On Fri, May 30, 2014 at 7:50 PM, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> 2014-05-31 0:18 GMT+01:00 Scott Howard <showard314 at gmail.com>:
>> On Fri, May 30, 2014 at 4:46 PM, Manuel A. Fernandez Montecelo
>> <manuel.montezelo at gmail.com> wrote:
>>> The versions are hardcoded to force reverse build-depends using the
>>> same versions, due to problems in the past (incompatibilities causing
>>> deadlocks when starting the application):
>>
>> Thank you for explaining. I'll update my package to follow ogre's
>> hardcoded version of boost manually to prevent that bug from
>> happening.
>
> Is that MyGui?

mygui and openmw.

I'm CC:ing Bret to this email, he's been maintaining them.

Bret: Ogre exposes the boost ABI, so to prevent situations where
previously compiled programs break when boost is bumped, ogre-1.9 is
hardcoded to a specefic library version.

Manuel, what do you think of this (please correct me if I'm wrong):
Since packages depending on ogre-1.9 are built against other libraries
that use boost-defaults, that causes them to FTBFS when the boost
transition occurs. Ogre-1.9 does not transition with the rest of the
archive. Packages really should depend on the version of boost in
boost-defaults otherwise the archive might become inconsistent (you
can see that 350 packages in the archive depend on boost, and ogre is
one one of 4 that do not depend on the default version defined by
boost-defaults). To keep the archive consistent and support the user
case defined in bug 674633 I propose
1) ogre-1.9 depend on libboost-dev
2) libogre-1.9-dev depend on: libboost-dev (which would pull in the
proper version and conflict for those users that are developing with
another library, addressing bug 674633).


Also:
"But it takes a bit of time, disk space (several GBs) of which I don't
have much at the moment, and probably binNMUs to reverse dependencies
just in case that something like that bug happens again (ogre-1.9
compiled with 1.55 and rdeps having been compiled with 1.54 from the
previous versions forced by ogre-1.9 could cause a problem similar to
the previous bug)."

That is what is supposed to happen when the whole archive transitions
to a new version of boost. If ogre had a BD on boost-defaults
(libboost*-dev), ogre and ogre's dependencies would have been binNMUed
by the team performing the transition. Instead, the whole archive
transitions, except ogre. Ogre's rdepends that also depend on either
libboost-default or any other library that depends on libboost-default
FTBFS and have to be removed from testing in order for the boost
transition to complete. This isn't very important now, since few
packages depend on ogre-1.9, but as the number of packages depending
on ogre-1.9 increase, it will become increasingly important to depend
on boost-defaults (libboost-dev).

The bug described in 674633 is unfortunate, it will never occur in a
stable release (were boost versions are not changing). I believe the
emphasis should be on maintaining archive consistency which will mean
users using unstable/testing as a development environment will break
on occasion. You can reduce the effects of that breakage by
build-depending on libboost-dev, thus forcing those users to also
upgrade their code/compilation to the new versions of boost as well.