https://bugzilla.redhat.com/show_bug.cgi?id=2443717
--- Comment #40 from Tarulia <[email protected]> --- I'm not a reviewer so obviously I don't make the call, but I want to raise my concerns about this here. (In reply to Scott Talbert from comment #39) > Most wxWidgets applications have > a way to specify the wx-config path when building, so I think this should > work. Otherwise, it is usually not hard to patch. IMHO that's a risky assumption to make. I'm not sure how "Most" was determined when we don't know every wxWidgets based application out there. This is a solution I mentioned in Comment 18, since that's how Arch does it. But as I said there, in the case of Aegisub for example I can't find such an option and the only reference to wx-config in the repo is for the Mac build: https://github.com/TypesettingTools/Aegisub/blob/1ee570d9b218b60523f8b3834e3b28b76bf9df5e/packages/meson.build#L14-L19 So "just patch it" is also not going to work because there is nothing to patch (or at least nothing I can find). Besides that I don't think it's a good idea to introduce distro-specific binary names that deviate from upstream docs. This means that application upstreams and/or developers would need to patch their build system around it (if even possible, see above), which is probably not going to come off great. For Fedora packagers that's a non-issue because it stays in the Fedora ecosystem, but putting that on upstreams and developers too is a different problem. With the way it is right now even compiling the wxWidgets provided samples would fail. Those are intended for developers that have not used wxWidgets at all before and how are they supposed to know about this? I can also see these users opening "fails to build" bug reports upstream about this, which also isn't great. Granted alternatives is also somewhat Fedora/RHEL specific (if we ignore the Debian heritage), but it is a standard utility, and at least it uses standard binary names. It is also intended for exactly this usecase, so I don't understand why we'd need to get rid of it? Sure it might be complex, but many packages are. (In reply to Neal Gompa from comment #38) > I worry about the complication > inside of build environments with alternatives. I have tried a bunch of different variants with this: Installing only one variant at a time, and installing both plus wxWidgets 3.2 and swapping with alternatives, none of which gave any issues. The one thing I haven't tried is building both a GTK and Qt variant of an application in the same spec file. I don't know whether swapping the symlinks with alternatives works in mock. But on that front it's questionable how relevant that really is given that none of our packages are actually built that way. IMO that's a "we cross that bridge when we come to it" situation. The only issue I found with it is the aforementioned wxrc problem, which is solvable. That's just my 2cents. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. 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%23c40 -- _______________________________________________ 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
