Closed dilyn-corner closed 2 months ago
Thank you for reporting us your feedback!
The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-2931.
This message was autogenerated
This has been fixed via a redesign: https://github.com/canonical/craft-parts/issues/620
Bug Description
When partitions are used, the paths for any particular step in the life cycle of a build are different than in cases where no partitions are present:
(Similarly for
parts/<part>/install
andprime/
)Suppose the below
override-stage
:Just in case no partitions exist, this will work as expected (
myFile
is created andsomeBinary
does some act using that file). In the case where partitions exist, two things change:1)
myFile
will be located in a different directory than one may think --stage/myFile
instead ofstage/default/myFile
2)local/bin/someBinary myFile
will fail entirely --someBinary
is not located inlocal/bin
, but insteaddefault/local/bin
The resolution to this issue is to specify a fully-qualified path,
Using a fully-qualified path isn't often documented or mentioned (at least in any snap-related documentation I've reviewed). Indeed, existing documentation indicates that the working directory for an override is is precisely
${CRAFT_STAGE|PRIME}
, and leverages non-fully qualified paths, see here.Changing where
${CRAFT_STAGE|PRIME}
are will break any existing (snap) builds which do not explicitly refer to.
with${CRAFT_STAGE|PRIME}
, which is a breaking change from current behavior.The failure happens in any broad situation where you would expect ENOENT, like:
As
bar/baz
is actually indefault/bar/baz
.To Reproduce
Install snapcraft from a feature branch and create a boilerplate snap:
Compare outputs from
snapcraft --verbose
using the belowsnapcraft.yaml
file, eliminating thecomponents: ...
stanza to see the current behavior.part yaml
Relevant log output