https://bugzilla.redhat.com/show_bug.cgi?id=2443717



--- Comment #18 from Tarulia <[email protected]> ---
Hm, a couple hours of experimenting later, it seems there is another problem
with this that might have to be brought up with upstream, but now it also makes
sense to me what the Arch PKGBUILD is doing.

So the problem is that %make_install always installs to the same
/usr/bin/wx-config, regardless of what toolkit it was built with. It is just a
symlink pointing to the toolkit's specific wx-config.

Since the spec is building both wxGTK and wxQt, this means that the second
%make_install clobbers the already existing symlink from the first
%make_install.

That in turn means that if the custom wrapper is removed like I did in my last
comment, that symlink now permanently points to wxQt because it happens to be
built and installed second:

> $ ls -l /usr/bin/wx*
> lrwxrwxrwx. 1 root root     33 Jul 26 02:00 /usr/bin/wx-config -> 
> ../lib64/wx/config/qt-unicode-3.3
> lrwxrwxrwx. 1 root root      8 Jul 26 02:00 /usr/bin/wxrc -> wxrc-3.3
> -rwxr-xr-x. 1 root root 132648 Jul 26 02:00 /usr/bin/wxrc-3.3

That of course means that all builds with only wxGTK installed (which would be
all wxW based packages right now) would FTBFS because wx-config couldn't be
found. I don't think the multi-arch wrapper is the solution here either though
since it always defaults to wxGTK and there is no way to choose wxQt instead,
making the wxQt build pointless.

I don't really know how upstream intends this to work. Arch "solved" this by
renaming the resulting wx-config[1][2], leaving the GTK one in place as the
default. But for one that seems like a rather hacky solution to me, and for
another I don't know how at application build time one would choose which to
use, and not even the wiki has a page on it. Even now I don't even know how I
would force an Aegisub build using the wxGTK backend that the current Fedora
repo version does.
I can't imagine always returning an arbitrary default that the developer has no
control over is intended, but on the other hand I don't see wx-config returning
anything for higher level buildsystems (i.e. meson, cmake, ...), only flags to
add to the compiler directly.

Of course this would be solved by not shipping wx-config in wxBase, but in the
respective toolkit packages instead. That would be fine for building packages,
but obviously that would mean you couldn't coinstall them during development.
I'm not sure what the best route is here.

[1]
https://gitlab.archlinux.org/archlinux/packaging/packages/wxwidgets/-/blob/c0b212c66bedce067d3706df31ea130b12bee65e/PKGBUILD#L122
[2]
https://gitlab.archlinux.org/archlinux/packaging/packages/wxwidgets/-/blob/c0b212c66bedce067d3706df31ea130b12bee65e/PKGBUILD#L214

PS: Sorry about all the walls of text (and emails), but I found all this just
going along :(


-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
https://bugzilla.redhat.com/show_bug.cgi?id=2443717

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202443717%23c18

-- 
_______________________________________________
package-review mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to