freebsd
pkg upgrade gets confused by conflicts on file moved from one package to another when both packages are being updated
While working at the XFCE 4.16 update here: https://github.com/madpilot78/FreeBSD-XFCE-4.15
I noticed a problem. A file has moved from libexo to xfce4-settings. Both packages have new versions.
In this situation pkg notices a conflict between the two:
xfce4-settings-4.16.0 [repo] conflicts with libexo-0.12.11 [installed] on /usr/local/etc/xdg/xfce4/helpers.rc
(xfce4-settings-4.16.0 being an update to xfce4-settings-4.16.x and libexo-0.12.11 being the old version which will be replaced by libexo-0.16.0)
and gets somewhat confused by this. It decides to install libexo-4.16.0 and later remove libexo-0.12.11:
Dec 30 11:26:24 tommy pkg[1978]: libexo-4.16.0 installed
[...]
Dec 30 11:26:25 tommy pkg[1978]: libexo-0.12.11 deinstalled
which is very problematic, because the later removal deletes essential files, like libexo .so libraries.
I fixed it locally with pkg upgrade -f libexo, which forces reinstallation of the missing files, but this is not good for usability.
I tried adding an explicit CONFLICTS_INSTALL to xfce-settings but it did not help.
What I'd expect is pkg noticing that libexo is anyway going to be upgraded and upgrade it, or at least perform the removal of the old version before installing the new one.
It just occurred to me, I could try to explicitly make libexo conflict with it's old versions, maybe that would push pkg solver in the right direction?
It just occurred to me, I could try to explicitly make libexo conflict with it's old versions, maybe that would push pkg solver in the right direction?
Since no information about conflicting packages shows up whatsoever in the +MANIFEST file in the package I guess that CONFLICTS_INSTALL has no effect on pkg.
I'll have to find some other kind of workaround.
It just occurred to me, I could try to explicitly make libexo conflict with it's old versions, maybe that would push pkg solver in the right direction?
Since no information about conflicting packages shows up whatsoever in the +MANIFEST file in the package I guess that CONFLICTS_INSTALL has no effect on pkg.
I have noticed this in the past, and been surprised by it. Whilst I realise pkg can make its own decision about conflicting packages, it is nice that the ports collection has a way to explicitly declare conflicts, and I think it would make sense for pkg to follow the CONFLICTS_INSTALL instructions in its solver.
My problem with this at present is that I'm working on updating XFCE to 4.16 and this pkg behavior is a show stopper, since a simple "pkg upgrade" with the new set of XFCE packages has a high probability to leave the system missing vital XFCE library and most XFCE programs refusing to run.
I'm trying to figure out a workaround and am open to suggestions.
Comment from @bapt on Twitter:
Pkg should deal with it just fine, it even have a regression test about it. But sometime it fails which is a bug that I failed to isolate into a simple so far, so not fixed yet
More from @bapt:
Once we hit a case it is repeatable, the problem is to isolate it in a small enough test case, some the complexity of the upgrade seems to be related to triggering the bug. So no I don t have a bulletproof recommandation [on how to proceed with the commit without causing breakage].
@madpilot78: is this issue repeatable for you? If so, this might be the opportunity we need to debug this issue.
@madpilot78: is this issue repeatable for you? If so, this might be the opportunity we need to debug this issue.
Yes 100% repeatable. I also have a VirtualBox VM where I can cause it every time. It also happened on all the 3 machines I use XFCE on.
A sure way to reproduce it is to create a Machine/VM with x11-wm/xfce4 installed from the official latest packages. Then switch to a repo generated with the xfce update and do pkg upgrade.
Tomorrow (CET) I can see if I can provide a pkg repository you can point to to trigger the bug.
@bapt @woodsb02
Tomorrow (CET) I can see if I can provide a pkg repository you can point to to trigger the bug.
I've published my test packages at https://pkg.madpilot.net/122amd64-xfce415.
The repo is signed, the pub key can be found in the read in https://github.com/madpilot78/FreeBSD-XFCE-4.15.
Having committed the xfce update, the reproduction steps I indicated in my previous comment will stop working shortly. Anyway I think I can create some specific testcase, I need some time though, I'll try to followup in a few days with something, if I can come up with it.
Having committed the xfce update, the reproduction steps I indicated in my previous comment will stop working shortly. Anyway I think I can create some specific testcase, I need some time though, I'll try to followup in a few days with something, if I can come up with it.
Actually it will still work for the virtualbox VM I created and the package set I have, so if some special command is required to debug or diagnose the issue I can run it.