Comment 1 for bug 1583250

Revision history for this message
Sebastien Bacher (seb128) wrote : Re: No way for dealing without distro patching configure DATADIR (and alike) path

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