upstream use of build-time defined PREFIX or DATADIR incompatible with snaps relocation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snapcraft |
Fix Released
|
High
|
Unassigned | ||
snapd |
Triaged
|
Undecided
|
Unassigned | ||
snapd (Ubuntu) |
Fix Released
|
Undecided
|
Cris Dywan |
Bug Description
A lot of projects are using --datadir= to ship ui data dir path. Those paths are store in a generated config.h at compile time most of the time.
However, using snapcraft autotools plugins, you can't get around it. Modifying --datadir (like settings it to /snap/<
This is typically the case for all gettext based project:
any gettext program calls
bindtextdomain ("domain", LOCALEDIR)'
to read translations
where LOCALEDIR is $prefix/usr/locale (set in a config.h)
tags: | added: snap-desktop-issue |
Changed in snapcraft (Ubuntu): | |
importance: | Undecided → High |
summary: |
- No way for dealing without distro patching configure DATADIR (and alike) - path + upstream use of build-time defined DATADIR incompatible with snaps + relocation |
Changed in snapd (Ubuntu): | |
assignee: | nobody → Christian Dywan (kalikiana) |
affects: | snappy → snapd |
That's an issue for most desktop (and probably non desktop ones as well) and not easy to workaround.
Typically autotools define a "datadir" based on the build prefix, if you prefix=/usr then datas go to /usr/share/ <name>/ <somefile> and then you get code doing things like
" if (!gtk_builder_ add_from_ file (builder,
DATADIR "/gnome- dictionary- menus.ui" ,
& error)) "
There seems to be no easy way to deal with that at the moment and it's blocking snappy trivial desktop softwares, some guidance on what to do would be useful.
Some possible options we can see
* have some patch over the upstream code that is applied before the build
Trevinho has an example with a custom snapcraft plugin to do that, it works but
- it means applications have to be "fixed" to be snap-ed which might be non-trivial/lead to bugs
- it requires maintaining a patch over the upstream code (until the change are upstreamed/merged which is likely to be rejected by upstream if the changes are snap specific
Note that encoding a runtime path at buildtime (/snap/ <name>/ current/ datadir/ filename) means the snap might stop working if the snap runtime changes in the futur, the alternative is to check for the env at runtime and have a dynamic path, but that's more code change
* find a way to define the right paths at buildtime
We didn't find a working solution so far since changing the prefix impacts on where the make install is putting files, also that means relying on a runtime behaviour that has no stability garanty (futur snap version might mount the fs in another location than /snap/name/current)
* divert syscalls with some sort of wrapper to append the snap prefix
that seems like non trivial work, hackish and not reliable
* get some part of the snap accessible under the snap "/" rather than "/snap..."
that would probably be the simplest/more efficient way but I guess there is probably some rational behind the design choice of having the squashfs showing under another subdir?
* other idea/solution?
Since that's blocking packaging on several applications having some recommendation of workaround/solution would be really nice