Skip to content

Conversation

@aszady
Copy link
Contributor

@aszady aszady commented Jan 14, 2026

To support the multi-arch proposal #166, the extension requires more sophisticated logic for the alias repository, particularly when a single package resolves to multiple RPMs (e.g. for different architectures).

Previously, the repository rule was responsible for the textual construction of alias target in the generated BUILD file. This approach is rigid and scales poorly when complex logic to handle more aliases is required. By extracting this logic into a dedicated macro, the repository rule is responsible only for providing structured metadata about RPMs. The logic determining how to expose that data (as an alias, a null rule, or perhaps a select in the future) is deferred to the macro. This decouples data resolution from target generation and allows utilizing more the expressiveness of Starlark.

This implementation tries to provide the equivalent logic as before. Minor changes include:

  • if an RPM repository was generated for other config, now the alias will be correctly generated (metadata is fetched from previous config via the registered_rpms shared dict);
  • not creating null_rpm_repository as alias generator macro can call null_rpm_rule directly.

This structure allows for future customisation, where users could potentially provide their own alias generation strategies if the default one doesn't fit their needs.

@github-actions
Copy link

github-actions bot commented Jan 14, 2026

⚠️ Optional job e2e-bzlmod-toolchain-circular-dependencies failed ⚠️

  • exit status: 1

@aszady aszady force-pushed the aliases branch 2 times, most recently from 3d99753 to dd66a8a Compare January 14, 2026 23:17
To support the multi-arch proposal rmohr#166, the extension requires more sophisticated logic for the alias repository, particularly when a single package resolves to multiple RPMs (e.g. for different architectures).

Previously, the repository rule was responsible for the textual construction of alias target in the generated BUILD file. This approach is rigid and scales poorly when complex logic to handle more aliases is required.
By extracting this logic into a dedicated macro, the repository rule is responsible only for providing structured metadata about RPMs. The logic determining how to expose that data (as an alias, a null rule, or perhaps a `select` in the future) is deferred to the macro. This decouples data resolution from target generation and allows utilizing more the expressiveness of Starlark.

This implementation tries to provide the equivalent logic as before.
Minor changes include:
- if an RPM repository was generated for other config, now the alias will be correctly generated (metadata is fetched from previous config via the `registered_rpms` shared dict);
- not creating `null_rpm_repository` as alias generator macro can call `null_rpm_rule` directly.

This structure allows for future customisation, where users could potentially provide their own alias generation strategies if the default one doesn't fit their needs.
aszady added a commit to aszady/bazeldnf that referenced this pull request Jan 15, 2026
Provide reliable data for identifying resolved RPM architecture for the purposes of the aliases generation (rmohr#176).
@aszady aszady marked this pull request as ready for review January 15, 2026 00:12
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.

1 participant