Hi Jochen, On 23/12/17 18:11, Jochen Sprickerhof wrote: > Hi Julien, > > * Julien Cristau <jcris...@debian.org> [2017-12-02 19:46]: >> I don't think the release team is willing to routinely do this without >> understanding why we're doing it, so an explanation for why these would >> be necessary is welcome. > > I gave some insides in this same bug in https://bugs.debian.org/868355#15. > Can you be more specific if you need more information?
I still don't quite understand what the exact problem is. You talk about the "one definition rule", but my question is, why does that matter? If your project uses Eigen but doesn't export any Eigen symbols on its API/ABI, then it doesn't matter if a newer version of Eigen changes definitions, structs, or anything else. A third project using both Eigen and your project wouldn't be affected by the different Eigen version than your project was built with, because your project doesn't expose Eigen at all. Now, it'd be a different case if your project exposed part of the Eigen ABI, and given there's no shared library, there can't be a SONAME bump so the only way to ensure there are no ABI mismatches is to ensure all projects are built with the same Eigen version. It's possible that I'm rather confused about how Eigen works, and that these strict build dependency checks are needed for a different reason. I am not familiar with Eigen, so that's why I need you to explain me why we need these checks. If they are needed for a good reason, I am OK with that and will be happy to schedule the binNMUs whenever they are needed. But if not, I'd like to avoid us doing unnecessary binNMUs. For reference, other projects have had strict version checks on the compiler. Those are generally not needed, and we've been able to disable those checks and talk to upstream about it. BTW I was going to schedule this binNMU for the time being in order to have a working ceres-solver, but it seems there was an upload since this request was opened. Do you need a binNMU now? If so I'll schedule it. Otherwise let's continue this conversation to clarify whether these binNMUs are required or they could be prevented. Cheers, Emilio
