Skip to content

ci: generate incorporation with pkg list -n instead of @latest #8185

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

iximeow
Copy link
Member

@iximeow iximeow commented May 17, 2025

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 the incorporation.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,

           -g path_or_uri
                   Use the specified package repository or archive as the
                   source of package data for the operation.  Repositories
                   that require a client SSL certificate cannot be used with
                   this option.  This option can be specified multiple times.
                   Use of -g implies -a if -n is not specified.

where -a is:

List installed packages and list the newest version of package that are not installed but could be installed in this image.

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 like consolidation/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 the helios / build TUF repo job runs on the helios-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 a helios-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 another 23359, so that bodes well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

helios is unintentionally pinned
1 participant