On 2018/05/25 22:55, Matthieu Herrb wrote: > On Fri, May 25, 2018 at 12:11:27PM +0100, Stuart Henderson wrote: > > > > Some packages depend on freetype AND another X lib that depends on freetype, > > Until new packages are available and the user has run pkg_add -u, this > > results > > in two conflicting versions of freetype being pulled in. > > > > WANTLIB is not the problem. WANTLIBs are correct. The packages do get > > updated once new packages are available, the problem is in the interim > > between bumping libs and new packages becoming available. > > > > Build times: > > > > aarch64 ~4 days > > amd64 1 day > > arm ~10 days > > hppa ~4 days > > i386 28-50 hours > > mips64 4 days > > mips64el 6 weeks > > powerpc ~2..3 weeks > > sparc64 ~2..3 weeks > > > > But unless bulk builders know that they need to restart builds, the previous > > build needs to finish before the new one can start, so it can be double > > those > > times before packages built against new libs are shipped. > > > > I don't know what the case is with libc/libm. We *do* do this type of > > bump in libssl/libcrypto/libtls because we know things break otherwise. > > And there is a clear problem with the freetype chain because it keeps > > happening again and again. > > > > By bumping the other libs e.g. fontconfig, already-installed software > > will continue to use the version of the other libs already on their > > disk, which uses the old freetype, avoiding the conflict. > > > > Ok, thanks. I keep forgetting about this delay in builing packages. > In that case I understand that it will help. > > So ok for the following diff and a (late) bump of the 3 mentionned > libs ? > > Index: shlib_version > =================================================================== > RCS file: /cvs/OpenBSD/xenocara/lib/freetype/shlib_version,v > retrieving revision 1.28 > diff -u -r1.28 shlib_version > --- shlib_version 21 May 2018 11:52:24 -0000 1.28 > +++ shlib_version 25 May 2018 20:54:40 -0000 > @@ -1,2 +1,4 @@ > major=29 > minor=0 > +# note: If bumping the major, also bump major for libXft, libXfont2 > +# and libfontconfig > > -- > Matthieu Herrb
Bumping would certainly help. Arches currently building packages look like this: $ grep libfreetype.so. */*sig.log aarch64/arm64-1.sig.log: /usr/X11R6/lib/libfreetype.so.29.0 aarch64/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.29.0 arm/armv7-1.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 arm/armv7-2.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 arm/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 hppa/hppa-1.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 hppa/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 i386/i386-2.sig.log: /usr/X11R6/lib/libfreetype.so.29.0 i386/i386.sig.log: /usr/X11R6/lib/libfreetype.so.29.0 i386/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.29.0 powerpc/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 powerpc/macppc-0.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 sparc64/localhost.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 sparc64/sparc64-0.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 sparc64/sparc64-2.sig.log: /usr/X11R6/lib/libfreetype.so.28.2 only fast arches already have 29.0 so won't be too badly hurt by bumping the other libraries now, and will help the slower-building arches. So OK with bumps. For the comment, I'm unsure what is needed when the minor is bumped, it depends whether ld.so picks up an exact match if available, or if it always looks for the highest minor version. The text we have in libcrypto's shlib_version is "Don't forget to give libssl and libtls the same type of bump!" so at least at some time somebody thought it was needed for minor bumps too. Someone else reading can probably give better advice on this.
