[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCHES] ImageMagick security updates without grafting

From: Maxime Devos
Subject: Re: [PATCHES] ImageMagick security updates without grafting
Date: Sat, 27 Mar 2021 15:36:07 +0100
User-agent: Evolution 3.34.2

On Sat, 2021-03-27 at 09:09 -0400, Mark H Weaver wrote:
> Hello Guix,
> Here's a proposed patch set that will henceforth enable us to freely
> update ImageMagick (and dblatex, and gtk-doc) on our 'master' branch
> without grafts.  This is done by adding variables 'imagemagick/stable',
> 'dblatex/stable', and 'gtk-doc/stable', which are then used as
> 'native-inputs' in selected packages.
> The idea here is that the overwhelming majority of dependencies on
> 'imagemagick' are via references to 'gtk-doc' in the 'native-inputs' of
> GNOME libraries.  The risk of running buggy imagemagick code within Guix
> build containers is presumably quite limited, and in any case, grafting
> is no better in this regard.

This approach (& patches) look good to me.

> [...]
> Are there any comments or objections to this approach?

What does ‘guix refresh --list-dependent imagemagick@6.9.11-48’
output now?  If it there are many dependent packages, could some
of them use imagemagick/stable, dblatex/stable or gtk-doc/stable
as well?

Maybe add a comment to imagemagick/stable on why there is a 
/stable variant, for future reference.  Perhaps something along
the lines of:

;; This is a variant of the 'imagemagick' package that is not
;; updated often.  Where possible, use this variant instead of
;; the updated 'imagemagick' package to avoid large rebuilds
;; each time 'imagemagick' is updated (e.g. with security fixes),
;; unless this causes security issues.
;; Normally the grafts mechanism would be used instead, but
;; imagemagick is a complicated package to graft.  See
;; <>.

>       Mark
> Note: I haven't yet fully tested these commits.

Note: I haven't tested your patches.


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]