On 2018/05/25 10:35, Matthieu Herrb wrote:
> On Fri, May 25, 2018 at 08:45:44AM +0100, Stuart Henderson wrote:
> > The usual problem with packages occurred.
>
> Hi,
>
> Can you give an example ? I still don't understand why this would be
> needed. We don't do that for libs like libm or other base system
> libs, as normally we keep track of inter-libraries dependencies almost
> everywhere. And as I understand it, newer ld will enforce that even
> more.
>
> From my experience, this is only a problem for packages with missing
> wantlib declarations. I did rebuild all the packages I'm using after
> the bump, and did'nt run in any issue for which I would blame missing
> another lib bump.
>
> I may be wrong, but I'd like to understand.
>
> >
> > Next time, please give the same type of shlib_version bump to the
> > other libraries in xenocara that depend on libfreetype, thanks!
> >
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.
----- Forwarded message from Stuart Henderson <s...@spacehopper.org> -----
From: Stuart Henderson <s...@spacehopper.org>
Date: Thu, 26 May 2016 15:03:09 +0100
To: David Coppa <dco...@gmail.com>
Cc: dera...@openbsd.org, Christian Weisgerber <na...@mips.inka.de>,
ajacou...@openbsd.org, Matthieu Herrb
<matth...@openbsd.org>
User-Agent: Mutt/1.6.1 (2016-04-27)
Subject: Re: Fwd: [UPDATE] freetype-2.6.3
On 2016/05/26 15:44, David Coppa wrote:
> On Thu, May 26, 2016 at 2:12 PM, Stuart Henderson <s...@spacehopper.org>
> wrote:
> > On 2016/05/26 11:57, Stuart Henderson wrote:
> >> On 2016/05/26 12:47, Christian Weisgerber wrote:
> >> > David Coppa:
> >> >
> >> > > Here's an update to the latest freetype release.
> >> > > Please put it in a bulk build.
> >> >
> >> > FYI, I'm running an amd64 bulk build with this.
> >> >
> >> > --
> >> > Christian "naddy" Weisgerber na...@mips.inka.de
> >>
> >> There were no freetype-related problems on i386 (just some
> >> stupid random java-looking breakage in libreoffice, I'm
> >> reattempting the libreoffice build now just to make sure
> >> there's nothing hidden in there)..
> >>
> >
> > Built this time. OK with me.
>
> This commit will bump libfreetype to 25.0 from 24.1.
>
> Since I do not want to repeat the mess that happened on 2015-06 when
> we went from 23.0 to 24.0, is there something particular I should do?
> Do we need to coordinate in some ways?
>
> Ciao!
> David
Ah yes. Looking back at icb logs 2015-06 was two problems.
One was that people didn't know the update was coming.
The other was that some libraries in X depend on freetype.
Therefore when someone used an old package that itself uses
freetype *and* pulls in an X library (say Xft) that also
depends on freetype, there's a conflict.
somepackage
| |
| `---- libXft
| |
| `-------- new libfreetype
|
`--------------------- old libfreetype
What you could do to avoid it is also bump the libs that
depend on freetype. Which I think is libXft and libXfont.
Then an existing package will pull in the *old* Xft and
old freetype, so it won't see the new Xft/freetype until
new packages are ready.
----- End forwarded message -----
----- Forwarded message from Stuart Henderson <s...@spacehopper.org> -----
From: Stuart Henderson <s...@spacehopper.org>
Date: Fri, 13 Jan 2017 16:35:34 +0000
To: David Coppa <dco...@gmail.com>
Cc: Matthieu Herrb <matth...@herrb.eu>, Matthieu Herrb <matth...@openbsd.org>,
na...@openbsd.org
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: FreeType 2.7.1
On 2017/01/13 17:14, David Coppa wrote:
> On Fri, Jan 13, 2017 at 11:18 AM, Matthieu Herrb <matth...@herrb.eu> wrote:
> > On Thu, Jan 12, 2017 at 02:17:02PM +0100, David Coppa wrote:
> >> On Thu, Jan 12, 2017 at 1:46 PM, Stuart Henderson <s...@spacehopper.org>
> >> wrote:
> >> > On 2017/01/09 15:29, David Coppa wrote:
> >> >> Here's the update to freetype-2.7.1, both inline and as attachment.
> >> >
> >> >> As usual, please test it.
> >> >>
> >> >> And, if you can, put it in your next bulk build.
> >> >
> >> > i386 bulk was clean.
> >>
> >> Thank you, Stuart.
> >>
> >> So... Ok to commit?
> >>
> >
> > Yes. ok matthieu@
> >
> > In my analysis of the changed symbols, only a minor bump was required,
> > but now that people have started installing libfreetype.so.28.0,
> > commit it like that.
>
> I thought about what Theo said about my previous updates:
>
> [16:23] <t> I very much doubt that libfreetype commit fits "only crank
> shlib minor"
> [17:38] <tedu> freetype also has some serious changes in behavior, not just
> abi
> [17:39] <t> I don't understand this idea of "crank the minor"
> [17:39] <t> If there is doubt, we crank the MAJOR
> [17:41] <tedu> done
>
> Ciao!
> David
The problem with that approach is that unless you bump the other
libs in X that depend on libfreetype (Xfont/Xft/fontconfig),
any packages that use both freetype and one of those other libs
will get library conflicts until new packages are available.
BTW I do similar to naddy for my test builds.
----- End forwarded message -----
