separate linux assets for non-FHS distros

[KiaraGrouwstra]

currently, the linux install script uses an inlined desktop entry and svg. to facilitate using these assets on distros that tend to segregate software packages tho, such as nixos, it would be desirable if such files were included separately, so as to make it easier to use the files while placing them in a different location (e.g. /nix/store/66lhkaswkzs2r4hx5w6k7qng38piprx1-yarr-2.4/).

[nkanaev]

Sorry, I'm not quite familiar with how segregated packages work. How does the actual packaging, installation and desktop integration work with such systems?

Can't the snippets simply be copy-pasted to separate files & adjusted in 3rd-party package projects?

[KiaraGrouwstra]

the packaging tends to work by (in this case bash) scripts that involve juggling around files from an upstream repo before/after their (respective) build process.

so in that sense, yes, files including the install-linux.sh can be copied into such a package. the tricky part there is it may not be desired to follow the same logic of having their resulting files copied to such specific locations.

while that could be worked around by then moving them to whatever desired location (or parsing the install script for the files (?!)), having them in separate files to begin with might lower that barrier a bit, allowing to then perhaps grab them while skipping this build script moving them to the home locations.

[nkanaev]

Content of yarr.svg is located in src/assets/graphicarts/favicon.svg (but without xml declaration).

And supposing that yarr.desktop is extracted to a separate file, how does a package manager set it's Exec path?

[KiaraGrouwstra]

good question, thanks for asking. :) desktop entries usually stay unaltered: the system would just ensure the relevant application binary would be exposed on the $PATH.

while in this example such a binary might really be located at /nix/store/66lhkaswkzs2r4hx5w6k7qng38piprx1-yarr-2.4/bin/yarr, their regular structure of exposing binaries (always directly under ./bin/ of its package directory) would ensure that they can use a fairly straightforward logic to construct such a $PATH (just expose ./bin/ of any package included in a system/user's configuration).

[nkanaev]

which means that either a package manager needs to construct a desktop entry file with the full path, or enforce users to setup proper $PATH after package installation?

[KiaraGrouwstra]

$PATH construction in practice is handled by the user opting to have the package added to their profile / system.

desktop entry rewrites to use full paths would be possible, allowing desktop entries to distinguish different versions of a package installed side by side, tho in practice such rewrites have not seemed common.

[nkanaev]

From a quick glance, nix seems to be capable of running shell scripts from package configuration. You'd need to adjust the content of the desktop file (full path to the binary and the icon) during installation anyways. Please consider providing your own scripts that way, since I can't guarantee the existence of the files for 3rd party vendors (see the example of such use case).