[bug#74253] [PATCH] transformations: Add multituned-package.

["Ludovic Courtès" <ludovic.courtes@inria.fr>]

Hi,

Efraim Flashner <efraim@flashner.co.il> skribis:

> * guix/transformations.scm (package-tuned-for-psabi,
> multituned-package): New variables.
>
> Change-Id: I09ac7ae9fc2bcd9aa712b3c30fef807bc7d55895
> ---
>
> This allows wrapping a package definition in multituned-package, ie:
>
> (define-public opus
>  (multituned-package
>   (package
>    ...)))
>
> I'm not sure where to go with this patch from here. This will provide
> the psabi libraries for x86_64 and powerpc64le so they get most of the
> benefits from tuning for the architecture but without needing to specify
> which architecture to tune for.  It should also provide a nice boost for
> guix packs and docker images and the like.
>
> The downside with using this by default is the larger package size due
> to the extra versions of the libraries, and if it is used then the
> regular --tune is disabled for that package.
>
> I think adding it as a '--tune=generic' or '--tune=psabi' would be a
> nice way to use it.

Should that be a package transformation though?  Could we instead have a
build system trick or the ‘multituned-package’ procedure exposed so
build the package several times and fill in lib/glibc-hwcaps?

That way, packagers would explicitly choose this technique for select
packages, which would then no longer need the ‘tunable?’ property.

The question becomes: how would we choose which packages is eligible to
this technique as opposed to ‘--tune’?  Intuitively, I would use that
for general-purpose packages like ‘opus’, but keep ‘--tune’ for more
niche/scientific packages.

WDYT?

Thanks,
Ludo’.