Build failed after adding new packages because the builder was assuming "bottlerocket-" prefix for all packages

[ziyuanchen-db]

I was experimenting on how to add new packages to the OS.

I followed https://github.com/bottlerocket-os/bottlerocket/blob/develop/packages/README.md and added a "hello-world" package.

cargo make -e PACKAGE=hello-world build-package worked fine.

I added this package to the aws-k8s-1.24 variant's Cargo.toml file, but then I got the error when running cargo make:

  #12 sha256:d3094bb85e0ae6d9583c0f8f7c8448c523129ad9e85d9eacc0d81a8eeb5db3ba
  #12 0.259 Directory walk started
  #12 0.259 Directory walk done - 175 packages
  #12 0.259 Temporary output repo path: ./rpmbuild/RPMS/.repodata/
  #12 0.259 Pool started (with 5 workers)
  #12 0.259 Pool finished
  #12 0.458 Added repo repo from ./rpmbuild/RPMS
  #12 0.623 repo                                            1.3 MB/s |  99 kB     00:00
  #12 0.932 No match for argument: bottlerocket-hello-world
  #12 0.941 Error: Unable to find a match: bottlerocket-hello-world

It seems that the builder container assumes all packages have the bottlerocket- prefix, and this prefix was automatically added to default packages. How can I resolve this issue for any packages I add?

[stmcginnis]

This can be a bit confusing. All of the RPM "packages" that are used when building Bottlerocket end up getting that "bottlerocket-" naming prefixed to the root name. So this particular error is misleading.

This type of message can happen when the RPM failed to build. That would be further back in the build output. There will be a different, more specific, error message stating why the hello-world RPM failed to build that will hopefully point to the more obvious failure reason.

The other possibility is that there is no variant or other package pulling it in to be built. Here is an example of a package being pulled in by another one, or pulled in by the variant definition.

You mentioned having added it to the aws-k8s-1.24 variant's Cargo.toml file, so I'm guessing it is the former case. But if not, please share a diff showing how you modified that Cargo.toml file and we can see if there is anything obvious that would explain why it fails.