The last update made gpsbabel "Exclusive" for qtwebengine arches, but I see qtwebkit can be also used. Could be gpsbabel update so qtwebkit is used on arches that don't provide qtwebengine? And if it can't, then could it build without the GUI for non-qtwebengine arches so at least the command line tool is available there (the spec file already supports that)? Version-Release number of selected component (if applicable): gpsbabel-1.5.4-6.fc27
The current state breaks deps for qlandkartegt, which requires the CLI gpsbabel for some actions.
(In reply to Dan Horák from comment #0) > The last update made gpsbabel "Exclusive" for qtwebengine arches, but I see > qtwebkit can be also used. Correct. > Could be gpsbabel update so qtwebkit is used on arches that don't provide > qtwebengine? Gpsbabel's upstream considers qtwebkit as insecure and "deprecated"/"dead". Unfortunately qtwebengine doesn't appear to be in a shape to replace qtwebkit all fedora architectures. That said, I don't want conditionally build against qtwebkit on those architectures not supported by qtwebengine, because it would add conditional build-/runtime-deps (and bugs). > And if it can't, then could it build without the GUI for > non-qtwebengine arches so at least the command line tool is available there > (the spec file already supports that)? Technically this would be possible, but I am not sure I want to do this.
For now, I've re-added the non-GUI-packages to those archs, which do not support qtwebengine (and removed the ExclusiveArch). However, I am still not sure, whether this is a clever or a stupid idea. Actually, I'd prefer the "hard cut", to make the regressions/management mistakes drawn by gpsbabel, qt and FESCO visible.