Date: Sat, 19 Jun 2021 12:58:18 -0700 From: Kevin Bowling <kevin.bowling@kev009.com> To: Baptiste Daroussin <bapt@freebsd.org> Cc: Kevin Bowling <kbowling@freebsd.org>, ports-committers <ports-committers@freebsd.org>, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: b44acc9409bd - main - graphics/mesa-libs: enable libglvnd support Message-ID: <CAK7dMtD-YmNSnOZVpwMZxV6i2SxU6Hv5cd9B7j4js2L0=RMp3Q@mail.gmail.com> In-Reply-To: <d66fad30-e277-4d60-bc43-634952cda641@FreeBSD.org> References: <202106170426.15H4Q4kS068821@gitrepo.freebsd.org> <1ac24e08-fe77-4cb1-934a-50439a71c72e@FreeBSD.org> <CAK7dMtBSkTujvQogs0W4rSzbU%2BU=1z05u3OEukdcPObrCdi7Uw@mail.gmail.com> <d66fad30-e277-4d60-bc43-634952cda641@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 18, 2021 at 4:44 PM Baptiste Daroussin <bapt@freebsd.org> wrote= : > > > 19 juin 2021 00:46:19 Kevin Bowling <kevin.bowling@kev009.com>: > > > On Fri, Jun 18, 2021 at 1:25 PM Baptiste Daroussin <bapt@freebsd.org> w= rote: > >> > >> > >> 17 juin 2021 06:26:08 Kevin Bowling <kbowling@FreeBSD.org>: > >> > >>> The branch main has been updated by kbowling: > >>> > >>> URL: https://cgit.FreeBSD.org/ports/commit/?id=3Db44acc9409bd3bdd92e8= 6e35c06d50e2134b02f2 > >>> > >>> commit b44acc9409bd3bdd92e86e35c06d50e2134b02f2 > >>> Author: Jan Beich <jbeich@FreeBSD.org> > >>> AuthorDate: 2021-06-16 15:48:02 +0000 > >>> Commit: Kevin Bowling <kbowling@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 t= he 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 bla= blabla message) > >> > >> To help it when you do such modification please bump portrevision of a= ll 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. Bu= t 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 r= ebuilding reverse dependencies - for people who wonder -). So probably only= bumping reverse dependencies where after this change no metadata changes i= s probbaly sufficient. Xephyr for instance is imho only depending on mesa-l= ibs 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 so= lver in all possible cases, so I am not 100% sure. To be fair writting thos= e explanations for you (sincerly thank you for asking me to explain it in t= his particular case) made me think of a corner case which might help me bei= ng 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK7dMtD-YmNSnOZVpwMZxV6i2SxU6Hv5cd9B7j4js2L0=RMp3Q>