ci: generate incorporation with pkg list -n instead of @latest #8185
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this is exactly the change @citrus-it suggested here to fix #8176. i've mostly just been convincing myself i understand what exactly this changes.
my understanding is: the broad strokes of #8092 included always creating an
incorporation.p5p
(... package archive ...? i've had a very hard time learning the appropriate terms here), then using that to constrain the available packages. pinning is just using theincorporation.p5p
produced at release-packaging-time instead of generating a fresh one. given a fresh one, notionally it should be the latest versions of all packages, and not actually imposing a constraint.the issue then is:
pkg list -g ...
implies-a
,where
-a
is:this wasn't super clear about what happens if a package is both installed and a newer version of that package is available, but it seems in practice the answer is "list the installed version, not a new version". in the case of a package like
/system/kernel
, that's already installed (surprise), carrying on through to more visible packages likeconsolidation/osnet/osnet-incorporation
. so, it's less that Helios was pinned as much as we were very committed to whichever bits are present when a TUF is built. given that thehelios / build TUF repo
job runs on thehelios-2.0
host this wouldn't even have been obvious up front since that's also probably relatively recent versions of everything. though before now i hadn't really wondered how ahelios-2.0
comes to be...-n
as Andy suggested always shows the newest version of packages, avoiding... this. passing-af
with an FMRI of*@latest
might also do, but-n
seems more straightforward.the TUF built with 3a173a0 mentions
[email protected]
, rather than yet another23359
, so that bodes well!