Guillermo:

This is going to happen for every [GNU/]Linux distribution that is not Debian, Arch, CentOS or RHEL. It does not... uh... look very portable :/


That is a reflection of reality. It isn't very portable. But you are misidentifying what it is. It is the location of these various off-PATH executables, which have at least four different possible locations; and the name of the user that runs the system-wide Desktop Bus broker. Yes, the people who have packaged these up don't agree on the same off-PATH locations; and their names are not very portable; and they don't agree on system account names. If you can work out which of the existing four Gentoo's packaging for things like at-spi-bus-launcher is most like, like M. Caravia did for Arch Linux, I'll put in some mappings for Gentoo. But do not blame the messenger for the news that GNOME confd is in four different places across Arch Linux, RedHat Linux, Debian/Ubuntu Linux, and FreeBSD/TrueOS.

You might find that Gentoo mainly or wholly follows the pattern of one of the others. But from mine and M. Caravia's experience of operating systems not even being entirely *self* consistent in this area, with no overall pattern being followed even for Desktop Bus softwares on a single operating system, you probably shouldn't raise your hopes about that. (-:

And yes, M. Caravia originally worked these out as a set of patches for Arch Linux, working out what should happen for arch:* .

Guillermo:

Additionally, the convert/per-user/*.do scripts' 'read_os' function calls 'exec' via absolute path /bin/exec instead of relative path ../../exec, which is not going to work if nosh isn't already installed (chicken and egg).


There's no chicken and egg problem. The external formats configuration import requires (amongst others) the nosh-exec package. There is no requirement in the opposite direction, so simply install nosh-exec first. This happens automatically with the provided packaging for FreeBSD/TrueOS and Debian, and with M. Caravia's Archnosh packaging, because of nosh-bundles depending from nosh-exec. If one installs the former, the package managers will have made sure that the latter is installed too.

Moreover that is not the relative path from your $HOME/.config/service-bundles/convert/ directory to /bin . Not that there of course *is* a stable single relative path for such a thing, given that home directories can be anywhere from /export/home/guillermo to /var/lib/mysql . Nor that, as mentioned, such a relative path is needed, given that one installs the toolset before running the external configuration import.

Reply via email to