From: ludo@gnu.org (Ludovic Courtès)
Subject: Re: [PATCH] gnu: kdbusaddons: Embed path to kdeinit5, avoid 
dependency cycles.
Date: Thu, 15 Dec 2016 17:06:19 +0100

> Other options that come to mind: (1) make ‘QT_PLUGIN_PATH’ and
> ‘QML2_IMPORT_PATH’ search paths of ‘kinit’; or (2) add a “profile 
> hook”
> that creates a file containing the search path, and patch kinit to 
> honor
> that file somehow.
>
> Option 1 sounds better, but ‘QT_PLUGIN_PATH’ really belongs to Qt, 
> not
> to kinit.

I think adding QT_PLUGIN_PATH to kinit (and a number of other KDE 
packages) could be justified. KDE applications heavily rely on 
QT_PLUGIN_PATH (and use a different path than the default path used 
by Qt: ${PREFIX}/lib/plugins instead of ${PREFIX}/plugins).  See for 
example the section on environment variables at 
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source

However, I'm not sure it's enough: as far as I understand, 
search-paths will only work for packages directly installed in a 
user's profile, but KDE applications often need plugins provided by 
their dependencies (e.g. for kdevelop, plugins from kdevplatform and 
kinit must be found on the QT_PLUGIN_PATH, but a user who installs 
kdevelop shouldn't be forced to install kinit and kdevplatform in 
their profile?). (Perhaps I misunderstand how search-paths works)

So, provided option (2) can somehow find the paths of dependencies as 
well, maybe that's better? (Are there examples of such a “profile 
hook” somewhere?  I didn't find anything in the manual).

>> +;; This version of kdbusaddons does not use kinit as an input, 
>> and is used to
>> +;; build kinit-bootstrap, as well as bootstrap versions of all 
>> kinit
>> +;; dependencies which also rely on kdbusaddons.
>> +(define kdbusaddons-bootstrap
>> +  (package
>> +    (inherit kdbusaddons)
>> +    (source (origin
>> +              (inherit (package-source kdbusaddons))
>> +              (patches '())))
>
> Since ‘kdbusaddons’ doesn’t have any patches, you can omit this 
> ‘source’
> field.

This commit adds a patch to kdbusaddons (the one that adds the kinit 
store directory), so I think does become necessary?

> [...]
>
> Isn’t it enough to do:
>
>   (define kinit-bootstrap
>     ((package-input-rewriting `((,kdbusaddons . 
> ,kdbusaddons-bootstrap)))
>      kinit))
>
> ?  Remember that ‘package-input-rewriting’ replaces inputs 
> recursively.

Yes, ..., yes it is :-) I had this nagging feeling that tracking the
dependency chain like that could be automated, and therefore probably
already _had_ been automated in guix :-) I didn't pay attention to the
word “recursive”... would have saved me a lot of work (you should have
seen the first versions of this patch O_o).

> You can check with ‘guix graph -e '(@ (gnu packages kde) 
> kdeinit-bootstrap)'’
> whether you’re really getting what you want.

tangentially: this seems to work only if I make the kinit-bootstrap 
package a public variable?

>> diff --git a/gnu/packages/patches/kdbusaddons-kinit-path.patch 
>> b/gnu/packages/patches/kdbusaddons-kinit-path.patch
>> new file mode 100644
>> index 0000000..97c7319
>> --- /dev/null
>> +++ b/gnu/packages/patches/kdbusaddons-kinit-path.patch
>> @@ -0,0 +1,15 @@
>> +Add placeholder for kinit's store path.
>
> s/path/file name/ please.  :-)
>
> In GNU “path” traditionally means “search path.”

I'm happy to comply, but note that the info manual does talk about 
store paths.  Should this be changed?

   https://www.gnu.org/software/guix/manual/html_node/The-Store.html

(Also, I chose “store directory” instead of “store file name”)

Thomas