Re: [Libguestfs] Fwd: libnbd | Failed pipeline for master | 2e381ac2

On Fri, Aug 27, 2021 at 11:16:25AM +0100, Daniel P. Berrangé wrote: >On Fri, Aug 27, 2021 at 11:09:13AM +0100, Richard W.M. Jones wrote: >>>From the log: >>https://gitlab.com/nbdkit/libnbd/-/jobs/1540375264 >> >>opensuse zypper seems to be failing with a recoverable error: >> >>Resolving package dependencies... >>Problem: the to be installed glib2-devel-2.68.3-4.1.x86_64 requires 'libglib-2_0-0 = 2.68.3', but this requirement cannot be provided >> not installable providers: libglib-2_0-0-2.68.3-4.1.i586[repo-oss] >> libglib-2_0-0-2.68.3-4.1.x86_64[repo-oss] >> Solution 1: downgrade of libglib-2_0-0-2.68.4-1.1.x86_64 to libglib-2_0-0-2.68.3-4.1.x86_64 >> Solution 2: do not install glib2-devel-2.68.3-4.1.x86_64 >> Solution 3: break glib2-devel-2.68.3-4.1.x86_64 by ignoring some of its dependencies >>Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c >> >>I wonder if this is something that libvirt-ci should handle better? >> >>I found this thread which seems to indicate there's no way to force >>zypper to pick an option: >>https://www.linuxquestions.org/questions/suse-opensuse-60/how-to-pre-select-solutions-1-or-2-in-autoyast-xml-config-file-4175688006/ >>which is kind of annoying. But maybe --force-resolution is worth a try? > >I've not tried that option, but I will say that openSuse Tumbleweed >seems to hit these broken dependancy problems fairly often. I'm >increasingly inclined to say it is too unstable to be worth having >in CI, unless it is marked "allow_failure: true" so it doesn't >block the pipeline > I actually had an idea for that. There is an option despite what is in the link (as that one is slightly unrelated I think). I was thinking earlier about adding --allow-downgrade to all zypper install invocations in libvirt-ci, but by the time I got to writing the patch it fixed itself and I could not reproduce it. Just like now with this issue.

There are couple more "Expert options" but I did not think very hard about using the other ones. Anyway, here's the list: --allow-downgrade --no-allow-downgrade Whether to allow downgrading installed resolvables. --allow-name-change --no-allow-name-change Whether to allow changing the names of installed resolvables. --allow-arch-change --no-allow-arch-change Whether to allow changing the architecture of installed resolvables. --allow-vendor-change --no-allow-vendor-change Whether to allow changing the vendor of installed resolvables. Should I write the patch for --allow-downgrade?