On Sun, Jan 12, 2020 at 08:44:43PM +0100, Marius Bakke wrote: > Jakub Kądziołka writes: > > > * gnu/packages/patches/qtbase-use-xdg-open-in-store.patch: New file. > > * gnu/packages/qt.scm (qtbase)[source][patches]: Apply the patch. > > [inputs]: Add a dependency on xdg-utils to get its store path. > > [arguments]: Add a new phase to patch the path into the source code. > > This patch does a lot. :-) > > With this patch, BROWSER and DEFAULT_BROWSER would no longer be > consulted, right? > > Does checkExecutable work with absolute file names? I.e. could we get > away by simply patching "xdg-open" with its store file name? Probably > should change the default browsers while at it, though. :-) > > Wrt the easy substitution, I think we should try and avoid introducing > changes to source code that depend on magic from #:phases. That way > people will still be (mostly) able to build Qt manually using the Guix > source. In this case, maybe defaulting to just "xdg-open" is enough? > > In short, I'm looking for an easier way to achieve the same goal, > without the rather intrusive patch. > > Copying Efraim as our resident Qt expert. I disagree about being a qt expert, I just like fixing packages :) Looking at the patch, I'm not in love with how there's a default list of browsers to look for. Looking at the code, it seems that if there's xdg-open available then open browser from the pre-defined list. What is the code around m_documentLauncher? Does that really need to be removed? I think our best bet would be to substitute xdg-open with the actual xdg-open binary around line 130 and to change the list of *browsers[] to ones we actually have in Guix. If we switched the list to {"icecat", "next", "chromium", "netsurf"} and made the substitution on xdg-open we'd be in a much better place than we are now. As it currently stands I know I don't have BROWSER or DEFAULT_BROWSER defined and we don't have any Debian-like package named 'default-browser' or similar that we could throw in. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted