On Mon, Mar 14, 2022 at 5:53 PM Ludovic Courtès <ludo@gnu.org> wrote:

> Next up: adding a “Writing Manifests” section.
>

Ludo',

I would find this quite helpful. The current "basic setup with manifests"
only documents the trivial case. It would be quite nice to document best
practices for custom UTF-8 profiles, system-dependent inclusion (should we
silently skip packages on unsupported systems?), and updating package
versions, inputs, and/or toolchain. And for the latter, what are the limits
of the manifest as compared with cloning, modifying, building, and
executing with "./pre-inst-env guix ..." (which loses reproducibility)?

Some background on that last thought: as Guix grows it becomes
increasingly difficult to upgrade popular dependencies. I looked at
upgrading 'fmt' and there was one dependent package that could not be
upgraded, though not a package I needed. I'd like to be able to define an
upgraded version of 'fmt' or 'boost' in my manifest and have it apply to
the entire installation (profile or pack) rather than needing to modify
specific packages with a with-input. Same for the toolchain, I think it
would be nice to simply say "create this installation using gcc-toolchain"
(the user default @11 rather than the system default @10) without needing
any package transformations. And could one specify global build flags such
as "-march=native"? Can one reach down into and modify commencement
packages?

Greg