Dpkg-build should be able to use quilt from host-tools
Hi, I've added this issue under buildstream's tracker despite it being for code in the bst-external project because the bst-external issue tracker is easily overlooked.
Currently, for a dpkg-build element to apply patches, it must use a version of
quilt that's part of the build. This is extremely inconvenient if quilt is
part of a circular dependency.
Equally, it should be possible to use a version of quilt that's built by buildstream, in case either:
- The host cannot have quilt (if buildstream ever runs on Windows, this won't be available)
- Quilt appreciably changes in behaviour between versions, so we have a version of quilt built by buildstream that we need to use.
My suggestion is:
- Add a config field to the dpkg-build element (e.g. "use-host-quilt").
- If left blank, it will use the host's quilt if found.
- If True, it will raise an error if the host does not have quilt.
- If False, it will use quilt installed on the system.
- If we're using the host's quilt to apply patches, we will need to replace the "patch" variable with a no-op before running configure-commands.
I am very open to reasons why we don't need to support running quilt both ways, since it adds a fair bit of complexity for a hypothetical we haven't yet encountered.
Activity
added Enhancement label
It's come to my attention that we already have a "patch" source plugin, so my previous concerns about confusion being caused by having source plugins modify one another may be unfounded.
I can see an argument for creating a "quilt" source plugin to apply the patches, instead of having the dpkg-build element do it for us, because there are cases (hypothetical for now) where elements other than dpkg-build may rely on quilt.
Should it be decided to use a separate quilt source plugin, then we will still need a way to disable dpkg-build using quilt from inside the sandbox.
The quilt source plugin has been merged into bst-external bst-external!19 (merged)
