[AppStream] Moving the AppStream collection metadata location

Matthias Klumpp matthias at tenstral.net
Mon Feb 14 14:43:56 UTC 2022


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

-- 
I welcome VSRE emails. See http://vsre.info/


More information about the AppStream mailing list