Bug 1481163

Summary: use qtwebkit for non-qtwebegine arches
Product: [Fedora] Fedora Reporter: Dan Horák <dan>
Component: gpsbabelAssignee: Ralf Corsepius <rc040203>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: cse.cem+redhatbugz, davejohansen, itamar, rc040203, rhbugs
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-14 13:41:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 467765, 1071880    

Description Dan Horák 2017-08-14 09:18:19 UTC
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

Comment 1 Dan Horák 2017-08-14 09:24:56 UTC
The current state breaks deps for qlandkartegt, which requires the CLI gpsbabel for some actions.

Comment 2 Ralf Corsepius 2017-08-14 11:04:24 UTC
(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.

Comment 3 Ralf Corsepius 2017-08-14 13:41:48 UTC
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.