Filter element unintentionally stages its indirect runtime dependencies recursively
Summary
Instead of only staging and filtering its single build-dependency's files as originally intended ("Only stages the direct build-dependency, skipping indirect dependencies."), the filter element also stages its indirect dependencies recursively. This creates a situation in which a filtered element can contain more files than the element it filters.
Steps to reproduce
- Download the following minimal reproduction example and extract it. Its element dependency graph is the following:
filters runtime-depends output-include.bst -----------------> input.bst -----------------> base.bst
- Use the following commands inside the extracted directory:
bst build --track-all output-include.bst bst checkout --deps none --hardlinks output-include.bst checkout/output-include.bst bst checkout --deps none --hardlinks input.bst checkout/input.bst
- The contents of the checkout directory would then be the following:
checkout/output-include.bst checkout/output-include.bst/foo checkout/output-include.bst/bar checkout/output-include.bst/base-system <--- from base.bst checkout/input.bst checkout/input.bst/foo checkout/input.bst/bar checkout/input.bst/baz
What is the current bug behavior?
As can be seen above, output-include.bst would additionally contain base-system
, which was staged from base.bst.
What is the expected correct behavior?
base.bst is an indirect dependency of output-include.bst and should not have been staged nor filtered by output-include.bst.
Possible fixes
See MR below.
Other relevant information
- BuildStream version affected: %BuildStream_v1.2, %BuildStream_v1.4
Edited by Dor Askayo