[bug#73157] gnu: mscgen: Fix dependencies.

* gnu/packages/graph.scm (mscgen)
[inputs]: Add fontconfig, freetype, ijg-libjpeg, libpng, zlib.

Change-Id: If185bcb2f786f6493c20040b47e93440987d7243
---
 gnu/packages/graph.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


base-commit: 590904cca15922e6474fbd3a71af9b3a45b268af

Hello,

Sébastien Lerique <sl@eauchat.org> writes:

> * gnu/packages/graph.scm (mscgen)
> [inputs]: Add fontconfig, freetype, ijg-libjpeg, libpng, zlib.
>
> Change-Id: If185bcb2f786f6493c20040b47e93440987d7243
> ---
>  gnu/packages/graph.scm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/graph.scm b/gnu/packages/graph.scm
> index 5c985eaf5b..e987e656a0 100644
> --- a/gnu/packages/graph.scm
> +++ b/gnu/packages/graph.scm
> @@ -53,10 +53,12 @@ (define-module (gnu packages graph)
>    #:use-module (gnu packages datastructures)
>    #:use-module (gnu packages docbook)
>    #:use-module (gnu packages flex)
> +  #:use-module (gnu packages fontutils)
>    #:use-module (gnu packages gd)
>    #:use-module (gnu packages graphics)
>    #:use-module (gnu packages graphviz)
>    #:use-module (gnu packages gtk)
> +  #:use-module (gnu packages image)
>    #:use-module (gnu packages linux)
>    #:use-module (gnu packages machine-learning)
>    #:use-module (gnu packages maths)
> @@ -813,7 +815,7 @@ (define-public mscgen
>      (native-inputs
>       (list pkg-config))
>      (inputs
> -     (list gd))
> +     (list fontconfig freetype gd ijg-libjpeg libpng zlib))
>      (home-page "https://www.mcternan.me.uk/mscgen/")
>      (synopsis "Message Sequence Chart Generator")
>      (description "Mscgen is a small program that parses Message Sequence Chart
>
> base-commit: 590904cca15922e6474fbd3a71af9b3a45b268af

I've built this locally, and checked if references were retained to the
added inputs; it seems ijg-libjpeg is not retained as a reference, which
means it is unused at run time and could be left out (or perhaps it
tries to dynamically load it, in which case the dlopen calls could be
patched, but I doubt so).

--8<---------------cut here---------------start------------->8---
$ guix gc -R /gnu/store/jbdbq8kxy5956wkqg4qrvfdks776gfb1-mscgen-0.20 |
grep ijg-libjpeg
-> no output
--8<---------------cut here---------------end--------------->8---

Could you verify the above, and if my assumption is correct, send a v2
without the added ijg-libjpeg?

Hi! And thanks.

> I've built this locally, and checked if references were retained to the
> added inputs; it seems ijg-libjpeg is not retained as a reference, which
> means it is unused at run time and could be left out (or perhaps it
> tries to dynamically load it, in which case the dlopen calls could be
> patched, but I doubt so).
>
> --8<---------------cut here---------------start------------->8---
> $ guix gc -R /gnu/store/jbdbq8kxy5956wkqg4qrvfdks776gfb1-mscgen-0.20 |
> grep ijg-libjpeg
> -> no output
> --8<---------------cut here---------------end--------------->8---
>
> Could you verify the above, and if my assumption is correct, send a v2
> without the added ijg-libjpeg?
>

So just removing ijg-libjpeg results in

  Package 'libjpeg', required by 'gdlib', not found

and replacing it with libjpeg-turbo works. "libjpeg" on its own is just
not found (and not defined in the guix source I see
590904cca15922e6474fbd3a71af9b3a45b268af ).

Should it be the turbo one?

Hi Sébastien,

Sébastien Lerique <sl@eauchat.org> writes:

> Hi! And thanks.
>
>> I've built this locally, and checked if references were retained to the
>> added inputs; it seems ijg-libjpeg is not retained as a reference, which
>> means it is unused at run time and could be left out (or perhaps it
>> tries to dynamically load it, in which case the dlopen calls could be
>> patched, but I doubt so).
>>
>> --8<---------------cut here---------------start------------->8---
>> $ guix gc -R /gnu/store/jbdbq8kxy5956wkqg4qrvfdks776gfb1-mscgen-0.20 |
>> grep ijg-libjpeg
>> -> no output
>> --8<---------------cut here---------------end--------------->8---
>>
>> Could you verify the above, and if my assumption is correct, send a v2
>> without the added ijg-libjpeg?
>>
>
> So just removing ijg-libjpeg results in
>
>   Package 'libjpeg', required by 'gdlib', not found
>
> and replacing it with libjpeg-turbo works. "libjpeg" on its own is just
> not found (and not defined in the guix source I see
> 590904cca15922e6474fbd3a71af9b3a45b268af ).
>
> Should it be the turbo one?

It should be turbo to match the default libjpeg used in Guix; but rather
than being propagated from mscgen, it should probably be propagated from
gdlib, which seems to have it listed in its pkg-config files:

--8<---------------cut here---------------start------------->8---
$ find $(guix build gd) -name '*.pc' -execdir cat {} +
refix=/gnu/store/8rl0dz3982ms15j2j50myr89dkc3h5y5-gd-2.3.3
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: gd
Description: GD graphics library
Version: 2.3.3
Requires:
Requires.private:   zlib  libpng  freetype2 >= 9.8.3  fontconfig  libjpeg
Cflags: -I${includedir}
Libs.private:  
Libs: -L${libdir} -lgd
--8<---------------cut here---------------end--------------->8---

Anything listed in pkg-config 'Requires' or 'Requires.private' should be
propagated for the pkg-config machinery to work as expected.  This topic
is brushed in the manual (see info "(guix) package References"), where
'propagated-inputs' are documented.

Hello all, 

This was also an issue with php. I already submitted a patch adding these to propagated inputs of gd https://issues.guix.gnu.org/72943, but it got rejected in favor of adding the dependencies to php itself. That is because a lot of packages depend on gd and not many are affected. See the associated issue also for an alternative solution with patch to gd's pkgconfig file. 

Regards, 
Rutherther

Hi,

Rutherther <rutherther@protonmail.com> writes:

> Hello all, 
>
> This was also an issue with php. I already submitted a patch adding
> these to propagated inputs of gd https://issues.guix.gnu.org/72943,
> but it got rejected in favor of adding the dependencies to php
> itself. That is because a lot of packages depend on gd and not many
> are affected. See the associated issue also for an alternative
> solution with patch to gd's pkgconfig file.

Thanks for the reference.  I guess for now we are covered.