Summary: | sys-apps/portage-3.0.12 src_unpack environment race condition? | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Mike Auty (RETIRED) <ikelos> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | sam, xgqt |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info output |
Description
Mike Auty (RETIRED)
2021-01-03 11:48:40 UTC
The problem is that you can't refer to ${ARCH} in SRC_URI, since the value there needs to be constant, so you'll have to substitute amd64 or whatever in SRC_URI. (In reply to Zac Medico from comment #1) > The problem is that you can't refer to ${ARCH} in SRC_URI, since the value > there needs to be constant, so you'll have to substitute amd64 or whatever > in SRC_URI. Yes, this is metadata invariance: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-600007.1. The idea being we need to be able to generate e.g. a full Manifest on one machine which will work for all. (Also: nice to see Jellyfin being worked on - it's a great bit of software and I've been wanting to package it myself!) Thanks for the replies! Sorry I didn't specify, but SRC_URI did contain the constant values. As you can see from the error, the entry is missing from the manifest (because SRC_URI had the constants in it and so downloaded and created the manifest on the right file). I discovered that even so, during the src_unpack phase the variable couldn't be used immediately (without something else happening first). The issue has been resolved in the ebuild by using constants everywhere, but it seemed as though the variable not resolving at the start of src_unpack (which I understood to just be a bash function) but resolving ok later on was a bit weird? I'm happy to close the bug if it's not considered an issue, just curious as to what might be causing it. I've no idea whether it happens with other variables though... Maybe add this bug to devmanual or some doc about ${ARCH}. |