Skip to content

Mnaranjo/ignore circular dependencies in starlark#4

Open
manuelnaranjo wants to merge 6 commits intomainfrom
mnaranjo/ignore-circular-dependencies-in-starlark
Open

Mnaranjo/ignore circular dependencies in starlark#4
manuelnaranjo wants to merge 6 commits intomainfrom
mnaranjo/ignore-circular-dependencies-in-starlark

Conversation

@manuelnaranjo
Copy link
Member

No description provided.

RPM dependency tree is insane, it has cycles in it, for instance for
bash depends on glibc which depends on glibc-common which depends on
bash ( °-° ). Bazel wants DAGs as any decent build system, so the cycles
need to be fixed.

On the other hand consumers of bazeldnf don't care about glibc they want
to add bash to their setups (or whatever they wanted to add which may or
may not depend on something else and have a circular dependency), so we
can flatten the dependencies and avoid the loops for them.

To avoid the cycles we hack things a bit, we first register 1 repository
per available rpm in the lock file without dependencies, we call this a
blob repository. Then for each requested target (which most likely will
become an rpmtree) we link that target to a list of blob repositories.

When building the depset of the RpmInfo we will have cases where file
will be defined in the case of blob entries or not be defined in the
case of publicly facing RPM entries. Depsets are strict in terms of type
if the first entry is a file then everything is a file, same if it's
None so we need to hack things a little bit.

Only the alias entry in the public repository will depend on the rpm
target which will contain the dependency tree.
Now we should be able to pass the circular dependencies test
In the case there are duplicated entries in the alias mapping it doesn't
necessarily mean a failure mode, it may be due to multiple lock files
pointing to the same RPM given this RPM is unique this is not a problem,
if it would then bazel would fail to register the repositories
If the same lock file is registered multiple times we reach a bug where
blobs needs to be deduplicated
If the extension requests to make an rpmtree for a not known target in
the lock file we need to fail with a meaninful error message and not
just with a key not known error
Blobs are unique, there's a unique blob repository per rpm url we need
to deduplicate blobs are having multiple lock files may lead to
overlaping blobs otherwise
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