It would be useful to be able to define extra_envs environment variables dynamically from template variables. Some ebuilds, for example debian-sources and vanilla-sources, require variables to be available in multiple stages, in order to ensure that the final files have the correct names. One way to do it is to set them in body'; but, it seems cleaner to me to keep variables out of body and define them in extra_envsinstead, even if they aren't needed beforeinherit`.
For debian-sources, those variables are set by the generator and populated into extra_envs. For vanilla-sources, the generator is builtin-dirlisting, so the extra_envs need to be defined in the spec. I've had to fall back to Portage dynamic variables instead of template variables:
extra_envs:
- KERNEL_TRIPLET="${PV%-*}"
- MACARONI_KTYPE="vanilla"
- MACARONI_KVER="${KERNEL_TRIPLET}"
- MACARONI_KSUFFIX="mark"
- EXTRAVERSION="-mark"
- MOD_DIR_NAME="${PV%-*}-mark"
- LINUX_SRCDIR="linux-${PV%-*}-mark"
In order to make the transition to a future replacement for Portage smoother, I think we should encourage setting variables in a structured way like this, in extra_envs instead of body; and I think we should discourage using Portage-specific dynamic variables when we can use information from the generator instead.
It would be useful to be able to define
extra_envsenvironment variables dynamically from template variables. Some ebuilds, for exampledebian-sourcesandvanilla-sources, require variables to be available in multiple stages, in order to ensure that the final files have the correct names. One way to do it is to set them inbody'; but, it seems cleaner to me to keep variables out of body and define them inextra_envsinstead, even if they aren't needed beforeinherit`.For
debian-sources, those variables are set by the generator and populated intoextra_envs. Forvanilla-sources, the generator isbuiltin-dirlisting, so theextra_envsneed to be defined in the spec. I've had to fall back to Portage dynamic variables instead of template variables:In order to make the transition to a future replacement for Portage smoother, I think we should encourage setting variables in a structured way like this, in
extra_envsinstead ofbody; and I think we should discourage using Portage-specific dynamic variables when we can use information from the generator instead.