Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[Mark H Weaver]

Hi Léo,

Regarding your commit:

> From 2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd Mon Sep 17 00:00:00 2001
> From: Léo Le Bouter <lle-bout@zaclys.net>
> Date: Thu, 18 Mar 2021 11:12:51 +0100
> Subject: [PATCH] gnu: imagemagick/fixed: Redirect old sonames to new sonames.
> 
> * gnu/packages/imagemagick.scm (imagemagick/fixed)[arguments]: Add
> 'fix-compat-cheat-rename-so phase to redirect old soname paths (expected
> without grafting) to new sonames introduced by ImageMagick 6.9.12-0 and
> later. These sonames are probably not forward compatible but most probably
> backwards compatible so it should suffice until we remove the graft.
> ---
>  gnu/packages/imagemagick.scm | 24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/gnu/packages/imagemagick.scm b/gnu/packages/imagemagick.scm
> index 9ac15361b4..a3562f2e13 100644
> --- a/gnu/packages/imagemagick.scm
> +++ b/gnu/packages/imagemagick.scm
> @@ -143,7 +143,29 @@ text, lines, polygons, ellipses and Bézier curves.")
>                                    "6.9.12-2.tar.xz"))
>                (sha256
>                 (base32
> -                "17da5zihz58qm41y61sbvw626m5xfwr2nzszlikrvxyq1j1q7asa"))))))
> +                "17da5zihz58qm41y61sbvw626m5xfwr2nzszlikrvxyq1j1q7asa"))))
> +    (arguments
> +     (substitute-keyword-arguments (package-arguments imagemagick)
> +       ((#:phases phases)
> +        `(modify-phases ,phases
> +           (add-after 'install 'fix-compat-cheat-rename-so
> +             (lambda* (#:key outputs #:allow-other-keys)
> +               (with-directory-excursion
> +                   (string-append (assoc-ref outputs "out")
> +                                  "/lib")
> +                 (symlink "libMagick++-6.Q16.so.9.0.0"
> +                          "libMagick++-6.Q16.so.8.0.0")
> +                 (symlink "libMagick++-6.Q16.so.9"
> +                          "libMagick++-6.Q16.so.8")
> +                 (symlink "libMagickCore-6.Q16.so.7.0.0"
> +                          "libMagickCore-6.Q16.so.6.0.0")
> +                 (symlink "libMagickCore-6.Q16.so.7"
> +                          "libMagickCore-6.Q16.so.6")
> +                 (symlink "libMagickWand-6.Q16.so.7.0.0"
> +                          "libMagickWand-6.Q16.so.6.0.0")
> +                 (symlink "libMagickWand-6.Q16.so.7"
> +                          "libMagickWand-6.Q16.so.6"))
> +               #t))))))))

This is really nasty.  Why is imagemagick grafted, anyway?  I think it
can simply be updated without causing many rebuilds, no?

     Regards,
       Mark

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[zimoun]

Hi Mark,

On Thu, 18 Mar 2021 at 08:51, Mark H Weaver <mhw@netris.org> wrote:

> This is really nasty.  Why is imagemagick grafted, anyway?  I think it
> can simply be updated without causing many rebuilds, no?

--8<---------------cut here---------------start------------->8---
$ guix refresh -l imagemagick@6.9.11-48 | cut -f1 -d':'
Building the following 1269 packages would ensure 2404 dependent packages are rebuilt

$ guix refresh -l imagemagick@6.9.12-2g | cut -f1 -d':'
Building the following 2 packages would ensure 2 dependent packages are rebuilt

$ guix refresh -l imagemagick | cut -f1 -d':'
Building the following 2 packages would ensure 2 dependent packages are rebuilt
--8<---------------cut here---------------end--------------->8---

I am not in the graft dancing but I suspect something wrong here.  I
have never checked but intuitively, I thought that graft has the
priority so “guix refresh -l imagemagick” should display all the
dependents.  Note it is the same story as zstd.


Cheers,
simon

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[Mark H Weaver]

Earlier, I wrote:
> Why is imagemagick grafted, anyway?  I think it can simply be updated
> without causing many rebuilds, no?

Actually, I see now that it would cause many more rebuilds than is
appropriate for master.

  mhw@jojen ~$ guix refresh -l imagemagick
  Building the following 1270 packages would ensure 2403 dependent
  packages are rebuilt: [...]

Strangely, before I ungrafted imagemagick on my own private branch,
I asked guix the same question and got a very different answer:

  mhw@jojen ~$ guix refresh -l imagemagick
  Building the following 2 packages would ensure 2 dependent packages
  are rebuilt: cl-ltk@0.992 ecl-ltk@0.992
  
I knew this couldn't be right, but I thought I remembered it having
fewer dependencies.  Oh well.  Sorry for the noise.

       Mark

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[Leo Famulari]

On Thu, Mar 18, 2021 at 09:40:04AM -0400, Mark H Weaver wrote:
> I knew this couldn't be right, but I thought I remembered it having
> fewer dependencies.  Oh well.  Sorry for the noise.

It's relatively new that ImageMagick is depended on by so many packages.
I think we should look into this and see if we can significantly reduce
the number.

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[Mark H Weaver]

Leo Famulari <leo@famulari.name> writes:

> On Thu, Mar 18, 2021 at 09:40:04AM -0400, Mark H Weaver wrote:
>> I knew this couldn't be right, but I thought I remembered it having
>> fewer dependencies.  Oh well.  Sorry for the noise.
>
> It's relatively new that ImageMagick is depended on by so many packages.
> I think we should look into this and see if we can significantly reduce
> the number.

The following dependency chain seems to be responsible for most of the
imagemagick-dependent packages:

gtk+@3 -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblatex -> imagemagick

      Mark

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[Leo Famulari]

On Fri, Mar 19, 2021 at 08:14:03PM -0400, Mark H Weaver wrote:
> Leo Famulari <leo@famulari.name> writes:
> 
> > On Thu, Mar 18, 2021 at 09:40:04AM -0400, Mark H Weaver wrote:
> >> I knew this couldn't be right, but I thought I remembered it having
> >> fewer dependencies.  Oh well.  Sorry for the noise.
> >
> > It's relatively new that ImageMagick is depended on by so many packages.
> > I think we should look into this and see if we can significantly reduce
> > the number.
> 
> The following dependency chain seems to be responsible for most of the
> imagemagick-dependent packages:
> 
> gtk+@3 -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblatex -> imagemagick

Thanks, that's useful.

But, I think this dependency chain has existed for a long time (notes
about this at the end of my message).

I wonder if there is some newer change that has increased the number of
ImageMagick dependents. Maybe it's just that GTK+ is depended on by a
lot of packages?

Chris (cc-ed), is this something that Guix Data Service can help us
answer?

To clarify, the question is, what changed in the package dependency
graph that caused so many packages to transitively depend on
ImageMagick? Previously, we could update ImageMagick on the master
branch.

------
Exploring the history of the dependency chain, using trusty `git log`:

Dblatex was added in 2014, with a dependency on imagemagick.

Gtk-doc was added in 2015, with a dependency on dblatex.

at-spi2-core became dependent on gtk-doc in 2018. at-spi2-atk has
depended on at-spi2-core since it was added 2013

And gtk+ has depended on at-spi2-atk since 2013.

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[Mark H Weaver]

Hi Leo,

> On Fri, Mar 19, 2021 at 08:14:03PM -0400, Mark H Weaver wrote:
>> The following dependency chain seems to be responsible for most of the
>> imagemagick-dependent packages:
>> 
>> gtk+@3 -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblatex -> imagemagick

Leo Famulari <leo@famulari.name> writes:
> To clarify, the question is, what changed in the package dependency
> graph that caused so many packages to transitively depend on
> ImageMagick? Previously, we could update ImageMagick on the master
> branch.

I think you've answered your own question, below.

> Exploring the history of the dependency chain, using trusty `git log`:
>
> Dblatex was added in 2014, with a dependency on imagemagick.
>
> Gtk-doc was added in 2015, with a dependency on dblatex.
>
> at-spi2-core became dependent on gtk-doc in 2018. at-spi2-atk has
> depended on at-spi2-core since it was added 2013
>
> And gtk+ has depended on at-spi2-atk since 2013.

As you noted, at-spi2-core became dependent on gtk-doc in August 2018.
That's when the chain above was completed.  My memory of 'imagemagick'
not having many dependents was from before then, I think.

Thanks for looking into it!

      Mark

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:
> The following dependency chain seems to be responsible for most of the
> imagemagick-dependent packages:
>
> gtk+@3 -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblatex -> imagemagick

It occurs to me that we could add "stable" variants of the
'imagemagick', 'dblatex', and 'gtk-doc' packages.  The stable variants
would be used as native-inputs by our core packages, thus allowing the
normal variants of these packages to be updated freely on our 'master'
branch.  In particular, we could keep our 'imagemagick' package
up-to-date without grafting and without having to backport fixes.

What do you think?

      Mark

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[Leo Famulari]

On Sat, Mar 27, 2021 at 05:36:48AM -0400, Mark H Weaver wrote:
> > gtk+@3 -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblatex -> imagemagick
> 
> It occurs to me that we could add "stable" variants of the
> 'imagemagick', 'dblatex', and 'gtk-doc' packages.  The stable variants
> would be used as native-inputs by our core packages, thus allowing the
> normal variants of these packages to be updated freely on our 'master'
> branch.  In particular, we could keep our 'imagemagick' package
> up-to-date without grafting and without having to backport fixes.
> 
> What do you think?

I think it's the right approach, and I saw your patch that implements
it. I'll reply in more detail there.