reopen 749944 On Fri, May 30, 2014 at 7:50 PM, Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> wrote: > 2014-05-31 0:18 GMT+01:00 Scott Howard <showard...@gmail.com>: >> On Fri, May 30, 2014 at 4:46 PM, Manuel A. Fernandez Montecelo >> <manuel.montez...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
