Skip to content
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

Make application inventory generation kit agnostic #397

Open
ginglis13 opened this issue Oct 10, 2024 · 2 comments
Open

Make application inventory generation kit agnostic #397

ginglis13 opened this issue Oct 10, 2024 · 2 comments
Assignees

Comments

@ginglis13
Copy link
Contributor

Based on discussion in #384

When application-inventory is constructed for building a Bottlerocket variant, the bottlerocket- prefix of a package name is removed if the package is sourced from the bottlerocket-core-kit:

# Convert the JSON array to a map of 'bottlerocket-' prefixed names to unprefixed package names
# for search and replace in the installed application inventory.
jq \
--compact-output \
'map({ (.|tostring): (.|sub("^bottlerocket-";""))}) | add' <<<"${CORE_KIT_LIST}" \
> core-kit-replacements.json

Some options:

  • We could have a "remove vendor prefix" option somewhere for variant builders to make this decision for themselves

  • The inventory will list bottlerocket-glibc (etc) instead of glibc.

    • This option has implications for BRSAs defined in kits; the package-name must match exactly the package name that results in variant application inventory.

The latter is likely the simplest, however an overridden definition of %{__cross_os} or %{cross_vendor} would result in application inventory -> BRSA mismatch.

@cbgbt
Copy link
Contributor

cbgbt commented Oct 11, 2024

The latter is likely the simplest, however an overridden definition of %{__cross_os} or %{cross_vendor} would result in application inventory -> BRSA mismatch.

I hadn't considered this! Although, overriding those macros would mean that you are rebuilding the software, and the BRSAs in the core-kits advisory metadata may not apply anymore anyways.

@cbgbt
Copy link
Contributor

cbgbt commented Oct 11, 2024

I could see a case where a downstream would still want advisories to apply to their custom build, though.

e.g. suppose you are downstream "foobar" and you are rebuilding the kernel from bottlerocket-core-kit as "foobar-kernel-6.1" but you only apply a few minimal patches. You might wish, out of convenience, for upstream's advisory information to apply and alert you when you need to perform a rebuild. In that case it could be beneficial for your inventory to just rename "foobar-kernel-6.1" to "kernel-6.1".

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

No branches or pull requests

2 participants