Steve McIntyre <steve@einval.com> (2017-01-19): > 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! Yeah, thanks for the confirmation. > Is there anything we could do to fail the build if versions are out of > sync, rather than let a broken build through? Well, I think Aurélien mentioned it: ensure chroots are up-to-date. Tweaking the buildscript might do the trick, I suppose. AFAIUI, the build isn't broken every time there's a divergence in versions anyway; you're sometimes (un)lucky. Can't really devote time right now to investigating the “let's not copy stuff over if it's already present” suggestion… KiBi.
Attachment:
signature.asc
Description: Digital signature