On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:
>On 2017-01-19 01:53, Cyril Brulebois wrote:
>
>> It's been a while since I last looked at/understood mklibs stuff though,
>> feel free to fix my suspicions/conclusions.
>
>The long term solution is to package all the libraries into udeb
>packages. That way we can simply get rid of the mklibs pass.
>
>The workaround are to make sure the chroots are up-to-date (which should
>be the case now on the build daemons). An other alternative would be to
>avoid copying a library in mklibs if it is already present in the image.
>That might break if some very strict dependencies are used, though
>I guess the way the udebs are downloaded, they should always have the
>same or a newer version than in the chroot.
Thanks for the explanation - it's appreciated!
Is there anything we could do to fail the build if versions are out of
sync, rather than let a broken build through?
--
Steve McIntyre, Cambridge, UK. st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.
