Let "make install" do the right thing

[rderooy]

This way "make install" will install the icons, .desktop and .metainfo.xml file in the right location.

It also adds a new .desktop file and .metainfo.xml file.

The XDG_DATA_HOME check is needed for flatpak, as that uses /app instead of /usr such that also on flatpak it will install the files in the right location, and I don't need to clean things up afterwards in the flatpak post install.

The .desktop file for Catapult I will put into a separate pull request against the Catapult repository.

[rderooy]

Build failures have nothing to do with the PR. Both the Linux build and Windows MinGW build failure is because the automated build uses "ubuntu-latest" which for now still points to Ubuntu 18.04, and a recent change requires GCC8. This should resolve itself in the next weeks when "ubuntu-latest" is changed to 20.04.

[rderooy]

I just created a new flatpak build and Fedora Koji build for Release 17. The flatpak should be up in the next few hours, for the Fedora package, I have requested an update based on my Koji build.

Question: why was my PR still not approved? It would have allowed me to simplify the build processes for the flatpak and RPM.

[rderooy]

Is there any objection to merging this? It would help with packaging on Linux.

[m9710797]

@mthuurne: Can you review this?

[MBilderbeek]

@mthuurne please?

[MBilderbeek]

On IRC, @mthuurne asked the following things out loud (or put differently: had the following remarks):

< mth> I don't know if "os.geteuid() == 0" will break with Debian's fakeroot
< mth> when using pathlib.Path, ideally subdirs use '/' as an operator instead of concatenating the path strings
< mth> is XDG Linux-specific or does it apply to the BSDs as well?
< mth> the PR is probably mostly an improvement, but I'm not sure there won't be regressions or missed opportunities without spending a lot more time on it
< mth> usually if user dirs don't exist, the custom is to create them, not to skip that part of the installation

@rderooy Can you take a look at these remarks/questions?

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[MBilderbeek]

@rderooy please?

[rderooy]

@MBilderbeek this was submitted 3.5 years ago, I have lost interest to pursue this a long time ago, considering how long it took to even get an initial reply. The Fedora RPM package has lots of hacks to work around various issues by the make install process, which I was trying to clean up at the time, but to me it seems there is no to little interest in having it build and install cleanly on Linux.

But here is a quick stab at the question:

< mth> I don't know if "os.geteuid() == 0" will break with Debian's fakeroot

Why would it? It does not cause problems for Fedora's copr build system, which also uses fakeroot. I would say give it a try if you want.

< mth> when using pathlib.Path, ideally subdirs use '/' as an operator instead of concatenating the path strings

I suspect what you're trying to say, is that you prefer a syntax like:

Path(desktopShareDestDir, 'icons', 'hicolor', i + 'x' + i, 'apps').mkdir(parents=True, exist_ok=True)

Feel free to submit an update if you want. It should not make any practical difference.

< mth> is XDG Linux-specific or does it apply to the BSDs as well?

XDG is primarily targeting Linux. As far as I know, but I could be wrong, the XDG variables are not set by default on BSD, although there should not be anything preventing a user from setting them. That is why the section was marked for Linux only.

< mth> the PR is probably mostly an improvement, but I'm not sure there won't be regressions or missed opportunities without spending a lot more time on it

sigh...

< mth> usually if user dirs don't exist, the custom is to create them, not to skip that part of the installation

/usr/share or ~/.local/share are indeed expected to exist, which should normally be the case. If you want to force the creation, be my guest.

[MBilderbeek]

@mthuurne it's a fair point @rderooy is making, I think. I feel pretty bad about it, but the topic is far out of my expertise, so all I can do is ask you to either spend a little more time on this, or just say you are not interested to merge this.