Re: The package/inherit trap

[Maxim Cournoyer]

Hi Mark,

Mark H Weaver <mhw@netris.org> writes:

[...]

> I don't have time to write the doc, but I can offer a few words here.
>
> The fundamental question that needs to be asked, to decide whether to
> write (define DERIVED-PACKAGE (package/inherit BASE OVERRIDES ...)) or
> (define DERIVED-PACKAGE (package (inherit BASE) OVERRIDES ...)) is this:
> if BASE had a replacement, would it make sense to apply the same
> OVERRIDES to BASE's replacement to automatically create a replacement
> for DERIVED-PACKAGE?
>
> Consider 'kodi/wayland' as an example:
>
> __ (define-public kodi/wayland
> ____ (package
> ______ (inherit kodi)
> ______ (name "kodi-wayland")
> ______ (arguments
> _______ (substitute-keyword-arguments (package-arguments kodi)
> _________ ((#:configure-flags flags)
> __________ `(cons "-DCORE_PLATFORM_NAME=wayland"
> _________________ (delete "-DCORE_PLATFORM_NAME=x11" ,flags)))))
> ______ (inputs
> _______ (modify-inputs (package-inputs kodi)
> _________ (prepend libinput
> __________________ libxkbcommon
> __________________ waylandpp
> __________________ wayland-protocols)))
> ______ (synopsis "Kodi with Wayland rendering backend")))
>
> Suppose, at some future time, 'kodi' were given a replacement named
> 'kodi-with-fixes' to apply a security update.
>
> The question to ask yourself is this: would it make sense for
> 'kodi/wayland' to automatically be given a replacement field defined
> exactly as above except with (inherit kodi) changed to (inherit
> kodi-with-fixes)?
>
> If the answer is "yes", then use (package/inherit BASE OVERRIDES ...),
> and make sure that BASE is simply a variable name.
>
> If the answer is "no", use (package (inherit BASE) OVERRIDES ...), in
> which case any replacement of BASE will simply be dropped, and the new
> package will not have a replacement unless one is explicitly given in
> OVERRIDES.
>
> The rationale for 'package/inherit' is to ensure that, e.g., security
> updates applied to 'kodi' will automatically be propagated to
> 'kodi/wayland', and similarly for other packages.
>
> Unless I'm mistaken, the criterion given above is fully general, and
> thus sufficient on its own.  However, for the sake of reducing the
> cognitive load on contributors, one could proceed to enumerate simpler
> heuristics that can be used in common cases.
>
> For example, if OVERRIDES includes a new 'source' field, the next
> question to ask is: does the new 'source' field make an incremental
> change to (package-source BASE) e.g. by simply adding another patch?  If
> so, then 'package/inherit' might do the right thing.  However, if the
> new 'source' field doesn't even look at (package-source BASE), then it's
> certainly not going to work sensibly when applied to BASE's replacement.
>
> Another common case is when the package you're defining *is* BASE's
> replacement.  In that case, you certainly don't want to use
> 'package/inherit'.
>
> If you want to rename 'package/inherit', I'd suggest something like
> 'package/inherit-with-replacements'.
>
> Hope this helps.  Feel free to do as you wish without consulting me
> further.  I'm using a private branch that hasn't been merged with
> upstream Guix since April 2021, so your decisions won't affect me
> in any case.

Thank you, that is abundantly detailed and clear; I'll try adapting it
in our manual.

Cheers!

-- 
Maxim