git: b44acc9409bd - main - graphics/mesa-libs: enable libglvnd support

[Kevin Bowling]

On Fri, Jun 18, 2021 at 4:44 PM Baptiste Daroussin <bapt at freebsd.org> wrote:
>
>
> 19 juin 2021 00:46:19 Kevin Bowling <kevin.bowling at kev009.com>:
>
> > On Fri, Jun 18, 2021 at 1:25 PM Baptiste Daroussin <bapt at freebsd.org> wrote:
> >>
> >>
> >> 17 juin 2021 06:26:08 Kevin Bowling <kbowling at FreeBSD.org>:
> >>
> >>> The branch main has been updated by kbowling:
> >>>
> >>> URL: https://cgit.FreeBSD.org/ports/commit/?id=b44acc9409bd3bdd92e86e35c06d50e2134b02f2
> >>>
> >>> commit b44acc9409bd3bdd92e86e35c06d50e2134b02f2
> >>> Author:     Jan Beich <jbeich at FreeBSD.org>
> >>> AuthorDate: 2021-06-16 15:48:02 +0000
> >>> Commit:     Kevin Bowling <kbowling at FreeBSD.org>
> >>> CommitDate: 2021-06-17 04:25:27 +0000
> >>>
> >>>     graphics/mesa-libs: enable libglvnd support
> >>>
> >>>     PR:             246767
> >>>     Reviewed by:    kbowling
> >>>     Tested by:      kbowling
> >>>     Differential Revision:  https://reviews.freebsd.org/D25020
> >>
> >>
> >> As I privately told Kevin, I am now replying here as it can be useful for other committers.
> >>
> >> This commit causes a situation I would call an impossible upgrades. If you have an ancient version of mesa-libs installed you cannot uograde to the new version of mesa-libs you need to first remove mesa-libs then install libglvnd then install mesa-libs. Pkg knows how to deal with such situation up to a limit.
> >>
> >> So first it is complicated because during that manipulation the system is in an instable situation: lack of mesa-libs while things still depends on it.
> >>
> >> Second if anything installed depends on mesa-libs but does not itself has to be reinstall from the repo it will block the removal (sat solver blablabla message)
> >>
> >> To help it when you do such modification please bump portrevision of all reverse dependencies! It should have be done anyway but most committers often miss doing it.
> >>
> >> Best regards,
> >> Bapt
> >
> > I'm fine prepping a review of this, I just want to be clear, increment
> > PORTREVISION on around 800 ports that depended on mesa-libs?
> >
> > I've only seen the one report of SAT failures with xephyr so far.  The
> > SAT solver worked fine on my kde5 desktops.  But I'd like to
> > facilitate a smooth transition for everyone so happy to do whatever is
> > needed.
> >
> > Regards,
> > Kevin
> >
>
> Tl;Dr safest approach yes but one can probably be smarter

Ok, better to play it safe since this has a wide cardinality.
https://reviews.freebsd.org/D30824 is ready, I'd like to get it in
quick but would like to merge https://reviews.freebsd.org/D30817 right
before that if anyone can help with approvals.

> Bump everything which directly depends on mesa-libs is the safest way. But to be fair pkg tries to detect changes in metadata and is able to trigger reinstallation if needed (it is the reason why poudriere is aggressively rebuilding reverse dependencies - for people who wonder -). So probably only bumping reverse dependencies where after this change no metadata changes is probbaly sufficient. Xephyr for instance is imho only depending on mesa-libs and not on libglvnd after the change.

Yeah the pkg and poudriere system work very well.  This has been an
interesting learning experience for me too, I've been contemplating
improvements to ports itself, if I can compose the thoughts into a
proposal I'll send a note to ports-developers@ some time in the
future.  One thing that would help is to get most users out of the
business of using ports directly and instead viewing it as the meta
build system it is so we can wrangle issues like this in one place.  I
do appreciate that we handle this kind of dep work on the project side
instead of offloading it to users like some other packaging systems.

> I say probably here because you can imagine the complexity to test the solver in all possible cases, so I am not 100% sure. To be fair writting those explanations for you (sincerly thank you for asking me to explain it in this particular case) made me think of a corner case which might help me being able to automatically catch the Xephyr case here and makes upgrade more reliable for end users if I manage to write it is code now :)

I wonder what hps is up to :) https://github.com/hselasky/libhpsat

> Best regards,
> Bapt