ubuntu-image snap built out of trunk includes two versions of ubuntu-image
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu Image |
Fix Released
|
High
|
Łukasz Zemczak |
Bug Description
With the release of the fix for LP: #1673576, a new problem appeared. Due to the way the current snapcraft.yaml is formulated by having ubuntu-image included as part of the stage-packages, snapcraft installs two versions of ubuntu-image inside the snap.
The story for the 1.0snap2 release: there are two ubuntu-image versions - one in lib/python3.
In the past we only had the one in site-package + a modification made to PYTHONPATH to enable this location. This seemingly caused some problems on classic confinement, so Barry went on to drop the PYTHONPATH modifications altogether and just go with this route.
For me this is not acceptable behavior to have two versions preinstalled in the snap, even if only one is actually used (the one from the deb packages in this case). We need to decide which one to leave and which route to go. This then causes confusion when trying to investigate the snap contents, and in general is a dirty way to go.
Using the packaged version means we would have to create a ubuntu-image PPA where we would recipe-build .deb packages that then could be used with the snap recipe to generate automatic snaps for new commits. This would also require investigation to see how we can do this.
Using the source-installed version means we'll have to re-investigate LP: #1673576 and see what we can do to get that working in a different way.
Changed in ubuntu-image: | |
status: | New → In Progress |
milestone: | none → 1.1 |
Changed in ubuntu-image: | |
status: | In Progress → Fix Committed |
Changed in ubuntu-image: | |
status: | Fix Committed → Fix Released |
I would also have to get some additional knowledge regarding snapping packages, as currently this is all a bit vague to me.