/etc/os-release variant alt

[grasegger]

This question is about

• [ ] Installation
• [ ] Initializing / Cloning
• [x] Alternate files
• [ ] Jinja templates
• [ ] Encryption
• [ ] Bootstrap
• [ ] Hooks
• [ ] Other

Describe your question

Today I stumbled across a situation where I was not able to solve it using alts (even with a template):

For working on Fedora Silverblue I need to tell npm to use a different global path since it tries to write to a read only file system by default. However setting this for all machines would break my work setup with nvm. I know about contexts but this would only work as long as I don't use silverblue in any capacity at work.

My /etc/os-release:

NAME="Fedora Linux"
VERSION="37.20230304.0 (Silverblue)"
ID=fedora
VERSION_ID=37
VERSION_CODENAME=""
PLATFORM_ID="platform:f37"
PRETTY_NAME="Fedora Linux 37.20230304.0 (Silverblue)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:37"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://silverblue.fedoraproject.org"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-silverblue/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://github.com/fedora-silverblue/issue-tracker/issues"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=37
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=37
SUPPORT_END=2023-11-14
VARIANT="Silverblue"
VARIANT_ID=silverblue
OSTREE_VERSION='37.20230304.0

My (tiny) template:

# WARNING: Do not edit this file.
# It was generated by processing {{ yadm.source }}

{% if yadm.distro_family == "silverblue" %}
prefix=$HOME/.npm-global
{% endif %}
progress=false

[TheLocehiliosan]

yadm.distro_family is populated via the ID_LIKE value in /etc/os-release.

Do you think it would help to do something like this:

• Set a local class value within your bootstrap by running
  • yadm config local.class $(awk -F= '$1=="VARIANT_ID" {print $2}' /etc/os-release)
• And then use yadm.class in your template?

[grasegger]

Thanks for the reply @TheLocehiliosan

While I did not use the solution you proposed it nudged me in the right direction.

After some tinkering I landed on the following solution, which also allows me to rebase my silverblue to kinonite for example. I switched to esh for templating and I think it also makes it easier to document why there is an if:

# WARNING: Do not edit this file.
# It was generated by processing <%= $YADM_SOURCE %>

<% if type rpm-ostree > /dev/null; then -%>
# On rpm-ostree based systems rewrite the npm prefix to avoid trying
# to write to a read only mount.
prefix=<%= $HOME %>/.npm-global
<% fi %>
progress=false

[TheLocehiliosan]

Ah yes. That's a good solution and does make it more clear why that system is treated differently.

The "built-in" templating is very basic and really meant to allow some templating without much need for dependencies. But if you can use a more capable template processor it will open up the possibilities. 👍