search

myriadrf / LimeSuite

Driver and GUI for LMS7002M-based SDR platforms
https://myriadrf.org/projects/lime-suite/
Apache License 2.0
464 stars 182 forks source link

Use a proper setup for the Freedesktop files (and icons) #223

Open FFY00 opened 5 years ago

FFY00 commented 5 years ago

Right now we are installing the contents of https://github.com/myriadrf/LimeSuite/tree/master/Desktop to /usr/share/Lime/Desktop. This would require us to run the install script after installing the package. I can't even begin to understand why this was implemented like this in the first place, we are installing static resources, they don't depend on anything in the runtime. This is not only bad packaging but it also introduces a really unneeded dependency on imagemagick. It makes no sense dealing with the .desktop file and the icons like this. It's really simple to fix, just directly install the .desktop file and the icons to the correct location.

You can check the Freedesktop documentation related to the icons' path here: https://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout

guruofquality commented 5 years ago

Well since I did this particular work, heres my 2 cents.

Right now we are installing the contents of https://github.com/myriadrf/LimeSuite/tree/master/Desktop to /usr/share/Lime/Desktop. This would require us to run the install script after installing the package.

That depends on the packaging in question, for example the debian postinstall calls the install scripts.

I'm not sure what system you are packaging for, but you also have the option of disabling the install (-DENABLE_DESKTOP=OFF) and running the post install script from the source.

I guess cmake could call this too, but it seems to be something thats going to be linux and packing system flavor specific. What are you looking for specifically, or can you share a pull request?

we are installing static resources, they don't depend on anything in the runtime

What do you mean?

This is not only bad packaging but it also introduces a really unneeded dependency on imagemagick. It makes no sense dealing with the .desktop file and the icons like this. It's really simple to fix, just directly install the .desktop file and the icons to the correct location.

No, there is no dependency on imagemagick, the generated files for various standard sizes are checked in.

You can check the Freedesktop documentation related to the icons' path here: https://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout

But the install script uses the xdg-* installation tools to put these files in the proper place according to the freedesktop.org standard... I guess I don't understand the problem. I think that I'm using xdg- tools correctly and the icons and launchers seems to work last I checked. It would be helpful to hear about specifically whats wrong, or to get a patch or pull request.

FFY00 commented 5 years ago

First of all, reading my comment again I realized it sounds a bit harsh and maybe also a bit aggressive. That wasn't my intention at all so I apologize for that.

@guruofquality commented on Oct 1, 2018, 1:06 AM GMT+1:

Well since I did this particular work, heres my 2 cents.

Right now we are installing the contents of /Desktop@master to /usr/share/Lime/Desktop. This would require us to run the install script after installing the package.

That depends on the packaging in question, for example the debian postinstall calls the install scripts.

This should be avoided when possible.

I'm not sure what system you are packaging for, but you also have the option of disabling the install (-DENABLE_DESKTOP=OFF) and running the post install script from the source.

I guess cmake could call this too, but it seems to be something thats going to be linux and packing system flavor specific. What are you looking for specifically, or can you share a pull request?

That may happen but not regarding this. These paths are defined by Freedesktop so they should be the same across all distros. I don't know any distro that doesn't use Freedesktop standard, even if they existed, they shouldn't be using -DENABLE_DESKTOP=ON because .desktop files are Freedesktop specific.

we are installing static resources, they don't depend on anything in the runtime

What do you mean?

None of the resources varies depending on the runtime so a postinstall script is not needed.

This is not only bad packaging but it also introduces a really unneeded dependency on imagemagick. It makes no sense dealing with the .desktop file and the icons like this. It's really simple to fix, just directly install the .desktop file and the icons to the correct location.

No, there is no dependency on imagemagick, the generated files for various standard sizes are checked in.

Yes, sorry. I was reading make_scaled_icons.sh but I realize that's not called by the post install script.

You can check the Freedesktop documentation related to the icons' path here: standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout

But the install script uses the xdg-* installation tools to put these files in the proper place according to the freedesktop.org standard... I guess I don't understand the problem. I think that I'm using xdg- tools correctly and the icons and launchers seems to work last I checked. It would be helpful to hear about specifically whats wrong, or to get a patch or pull request.

It works but these tools are not intended to be used like this. There's no need for a /usr/share/Lime/Desktop. The paths are the same for every distro using the Freedesktop standard so the files can be installed directly by CMake.

guruofquality commented 5 years ago

So I think you can get away with installing these files into their respective directories using regular install methods. Other projects I have done this in have a mime type for the saved file format and the installation; which is more involved in regards of how the tools work because there is a mime cache and some other files that get updated but not overwritten. LimeSuite doesn't have its own file format per-say, but I suppose it could in the future with the saved ini files.

Question: There is a similar desktop icon/launcher install in gnuradio for GRC, and in this case it does use the mime type stuff. What does arch do in this case?

Also, with the freedesktop tools, the install directories for icons and desktop launchers get placed into two directories based on who runs the command:

So neither of these install paths are necessarily the same as the install prefix (think /usr/local for source builds on a dev machine). That may or may not be annoying for the causal developer installing this from source.

Given the above, I think that the best option is to have a install mode in the cmake for these files that can be turned on specifically when installing with /usr install prefix for linux platforms.

FFY00 commented 5 years ago

@guruofquality commented on Oct 6, 2018, 3:21 PM GMT+1:

So I think you can get away with installing these files into their respective directories using regular install methods. Other projects I have done this in have a mime type for the saved file format and the installation; which is more involved in regards of how the tools work because there is a mime cache and some other files that get updated but not overwritten. LimeSuite doesn't have its own file format per-say, but I suppose it could in the future with the saved ini files.

Question: There is a similar desktop icon/launcher install in gnuradio for GRC, and in this case it does use the mime type stuff. What does arch do in this case?

We manually install the files. This is not an optimal solution and should be reported to the upstream. I am not the maintainer so I can't really complain about it.

Also, with the freedesktop tools, the install directories for icons and desktop launchers get placed into two directories based on who runs the command:

  • /usr/share when run as root
  • or ~/.local/share when non-root

This can be configured in CMake using the install prefix. When you run as non-root you'll need set the CMake prefix to ~/.local, the icons can inherit that prefix, there's no need to run the freedesktop tools.

So neither of these install paths are necessarily the same as the install prefix (think /usr/local for source builds on a dev machine). That may or may not be annoying for the causal developer installing this from source.

Yeah, and /usr/local is a valid location to install freedesktop icons and luancher files. IMO the way things are done right now is more annoying as you'll need to run an extra command after installing. And when you run that command, the files are not tracked by CMake so they can't be automatically uninstalled.

Given the above, I think that the best option is to have a install mode in the cmake for these files that can be turned on specifically when installing with /usr install prefix for linux platforms.

No need, just install the files to $CMAKE_PREFIX/share/....