Thanks for submitting this.

The desktop file looks generally useful, and I think it should be installed by the build (if the gui is built). It seems useful to anyone installing unison with the gui, packaging or not. I am unclear on norms for where this typically goes in source trees.

The desktop doesn't have an embedded license, and there's no way to understand if there is one from where it came from in the PR. (I don't want to try to claim below threshold.) This is surely easy to address.

I will have to look to see what kind of packaging files are already present. In general there are a vast number of packaging systems and I am not inclined to have all of their control files in the unison repo. This appstream file sort of appears generic at first glance, but on reading it seems clearly a flatpak-specific packaging control file.

I am unclear on norms for where this typically goes in source trees.

same here; i looked at 3 relatively new applications on gitlab.gnome.org and they all put these files in a top-level directory "data" so i decided to follow that.

The desktop doesn't have an embedded license ...

hmm ... the Fedora policy is that the RPM spec files are MIT licensed, i suppose this could be extended to cover other files such as .desktop files if they originate in the same RPM git repo...

https://docs.fedoraproject.org/en-US/legal/misc/#_license_of_fedora_spec_files

This appstream file sort of appears generic at first glance, but on reading it seems clearly a flatpak-specific packaging control file.

Not really... oh there is the "servercmd" in the description; technically that is specific to having the Flatpak installed on the other machine to which you can connect with a client that's running a non-Flatpak build :)

but seriously, i had to put that somewhere where users see it as it's not obvious that the Flatpak build could be used on a "server" at all - this info really belongs in the manual.

the main way how this file became much larger than the one i started from is that the Flathub people require a lot of optional elements to be present, and wrote a linter to enforce it.

so i guess i could remove the 2 last paragraphs from the description... and maybe dig up the changelog of the latest release and add some items to the changelog element so it doesn't only mention Flathub... does that sound good?

It might be better to split this into two. For the desktop file, we'll need to resolve license, and I'd like to see it installed with the gui.

For 'appstream', it really reads like a "the wold is flatpak" ad. unison doesn't document that you can use packaging system X on the server in the manual and I don't see that changing. I don't follow the idea that people need to be told that packaging system X could be used on the server. There is a list of packaging systems on the wiki, and I just added this. I did find appstream on freedesktop.org. I guess that is for the source repo, and not installed, because it's about directories of packages, not by the user at runtime? Is there any use of it beyond Linux?

AppStream file adapted; the desktop file is removed and in a new PR at #1128

i don't fully understand how AppStream files are used - in the RPM case, they are installed with the RPM, but clearly that's not the whole story - on my Fedora system, Gnome Software evidently displays the data of the AppStream file for any RPM, including ones that i never installed - there must be some post-processing at the distro level to create some database out of all the RPM AppStream files.

so my understanding is that AppStream files are specific to Linux and specific to Linux package managers in the general sense - presumably it works on Debian in a similar way - but if you would build from source and "make install" then maybe there's no point to install an AppStream file with that because there's nothing that would read it from /usr/local or wherever.

Thanks; I retitled the PR to be appstream only. I will try to understand appstream a bit more. Until your PR I had never heard of it.

The file is supposed to be installed, to $prefix/share/metainfo. It is some blend of linuxy and portable, even if only GNU/Linux distributions are really building and using catalogs. (I don't want to cross into maintaining packaging-system-specific files for N package managers.) My system has 25 of them installed. That seems like enough precedent.

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent

The appstream file has io.github.bcpierce00.unison as the app id, and unison has not adopted an app id. I don't really want to point to an image on flathub, but it's easy to copy it to unison, assuming clear licensing.

I think this should be installed to $prefix/share/metainfo.

However, I'm not really sure if there is currently a path to progress on the app id issue, which is that unison doesn't have one and the appstream format insists on one. I'll bring this up on hackers.

yeah dunno you could of course use a different app id, then i can't use this xml file directly from upstream, but currently it's not in upstream so i don't lose anything :)

lets say the image is CC0-1.0 licensed? it is a bit simplistic though, i was in a hurry and cared more about the policy requirements than showing something fancy.

... and the one thing that annoys me about Flathub is that they require the image to be served from a HTTP URL, figuring out how to get it into a proper git repo took some creativity :)