[AppStream] Moving the AppStream collection metadata location

[Nate Graham]

Since we already have /usr/share/applications, perhaps the appstream 
metadata could go in /usr/share/applications-metadata. This folder name 
would have a logical connection to the place where apps' desktop files 
go, and be descriptive without using the project name.

Alternatively, perhaps they could all just go in 
/usr/share/applications, since from a certain point of view, the 
.desktop files in there are already a form of metadata, so we could 
consolidate all the app metadata into a single folder for simplicity.

Nate


On 2/14/22 07:43, Matthias Klumpp wrote:
> Hi!
> I would like to alter the location of the AppStream collection
> metadata, which is currently /var/(lib|cache)/app-info or
> /usr/share/app-info
> 
> Reasons for that are mainly two:
> 1) The app-info name sucks, as it is completely nondescriptive to what
> this directory is actually about, and has been a placeholder name
> scribbled on a whiteboard in 2011 that I used because I implemented
> the stuff that was on said whiteboard 1:1 in the early days of
> AppStream ;-)
> It actually regularly confuses users (developers) as to what the
> difference between this directory and /usr/share/metainfo actually is.
> 
> 2) By moving the location I could create a legacy-free directory,
> where for example the icon search is well-defined and the directory
> layout only follows "modern" AppStream, which would not only simplify
> libappstream's code, but also make it a bit faster as we could get rid
> of a ton of useless stat() calls for nonexistent directories and get
> rid of a bunch of heuristics around it. The compatibility code would
> remain only for the old location.
> 
> Reason not to make that change is that this path is quite old so I
> would have to keep compatibility code around for it for a really long
> time, possibly even after AppStream 1.0.
> The reason why I think this is not as much pain as originally thought
> is because other tools like Flatpak already place collection metadata
> files in different locations anyway that we have to scan, and the fact
> that there is very few tools that do not go through libappstream to
> read this data.
> So, the only tools that need adjustment are gnome-software, fwupd,
> appstream-glib and appstream itself, as well as possibly flatpak, and
> that is an amount of code that I can deal with and provide patches
> for. And since compatibility code would exist for a while, there
> wouldn't even be a major drive to get everything switched on a flag
> date, I'd imagine fwupd may stick with the old location for a long
> time.
> 
> So, what would a better name be? I thought about this, and besides
> something like /usr/share/appstream, which I don't like because it's
> encoding a project name, names like "swindex" or "swcatalog" made the
> most sense for me. These directories contain a catalog of available
> software, complete with icons and other auxiliary data, so that would
> be a very descriptive name. Anything with "component" in the name is a
> bit too long, and using my own abbreviation for component, cpt, as
> used in AppStream's source code, would only be confusing (cpnt would
> also be odd).
> 
> So, from all ideas I had, /usr/share/swcatalog felt like the best and
> most descriptive one (as "sw" is a very obvious abbreviation for
> software). The inside of this directory would look as usual, so you
> would have the xml/ yaml/ and icons/<origin> directories, with the
> latter following the AppStream specification and without random icon
> searches across the filesystem.
> 
> What do you think? Especially @hughsie on the naming side ;-) - I also
> promise that this is the last directory path I would rename for a long
> time ;-) In case someone brings up a good reason *not* to make this
> change (like, a wide use in $software that can't be adjusted as
> easily, or a lot of code other than 4 projects using it), I would
> reconsider this change. Otherwise I'm happy to provide patches.
> 
> Cheers,
>      Matthias
>