Conflicting files - sometimes

snapcraft
1

Hey,
In the fiduswriter snap there are files that exist in more than one part. In order to avoid any problems, I remove one of the two using the stage section [1].

Unfortunately, when snapcraft is building the packages, on some architectures there is still a conflict that shows up seemingly randomly [2], failing with this error message:

Failed to stage: Parts ‘fiduswriter’ and ‘fiduswriter-customizations’ have the following files, but with different contents:
lib/python3.8/site-packages/fiduswriter/configuration.py-default

Snapcraft offers some capabilities to solve this by use of the following keywords:
- filesets
- stage
- snap
- organize

On others the build is released without problems [3]. Any idea how to prevent this from happening?

[1] https://github.com/fiduswriter/fiduswriter-snap/blob/master/snap/snapcraft.yaml#L47

[2] https://snapcraft.io/fiduswriter/builds/1109031

[3] https://snapcraft.io/fiduswriter/builds/1109030

2

I don’t see anything obvious wrong with your snapcraft.yaml. The log file links you’ve given are not visible to anyone else, but it looks like they correspond to the ones here and here.

As for workarounds, perhaps you could try updating the fiduswriter part to include something like this:

    override-build: |
      snapcraftctl build
      rm $SNAPCRAFT_PART_INSTALL/lib/python3.8/site-packages/fiduswriter/configuration.py-default

… in place of the stage: stanza. If the file is not present in the part’s install directory, then it cannot cause a conflict.

As far as the root cause, I wonder if there’s some uncertainty about the order the parts are staged in with one order picked on amd64 and a different order picked on arm64? Perhaps with one of the orders, the parts.fiduswriter.stage directive is not being considered when deciding whether there is a conflict. Maybe @cjp256 has some ideas?

1 Like
3

I have reproduced this a number of times on arm64 using remote-build, though never locally.

Any thoughts @sergiusens? Have you seen this before? While check_for_collisions() may process parts in different orders, it’s unclear to me why it would affect the outcome in this case…