Support building without librsvg support

[nanonyme]

This implies Rust dependency and makes appstream a not great replacement for freedesktop-sdk. The dependency results in massive increase in dep chain length.

[nanonyme]

Not sure if related but we used to with appstream-glib disable fonts support compoletely. This seems not to be possible with appstream.

[ximion]

We need librsvg to render SVG vector graphics. You can build AppStream without librsvg by disabling compose support (-Dcompose=false), but if you do want to compose final catalog data, I see no way around librsvg - we need to process apps that ship SVG graphics after all.
The freedesktop-sdk already ships with AppStream by default, so I don't really see what the problem would be here... Can you elaborate? Even appstream-glib needed librsvg to render vector icons.

[nanonyme]

The problem mostly came with our reasonably minimal freedesktop-sdk Docker images growing Rust build dependency because of appstream. This is making supporting new arches quite a lot more challenging. If appstream-glib is using librsvg, there is no direct dependency between the two. Definitely there is no linkage.

[ximion]

If appstream-glib is using librsvg, there is no direct dependency between the two.

Yeah, it's using SVG rendering via GdkPixbuf loaders.
AppStream without the capability of processing SVG icons seems like a bad idea, especially since we are encouraging people to ship vector graphics. If rsvg support were optional, you could build a version of appstream-compose that would just reject some applications that don't ship with a pre-rendered icon of the right size, while other versions of ascompose that were compiled differently would support this. This kind of different behavior would be quite bad...

I am assuming that the SDK requires compose support and disabling compose is not an option either? (if you don't want to generate catalog data, libappstream is quite light in dependencies)
Also, the current freedesktop SDK 22.08 ships with AppStream, and the previous SDK 21.08 shipped with rsvg, so is that Docker version a stripped down even more minimal version that the official SDK?

Fun sidestory: At Ubuntu we actually ran into the issue with the Snap bundle for appstream-generator not containing rsvg support, and learned that way that it is really essential to process a ton of apps (pretty much 100% of all KDE apps and most modern GNOME apps). I am also really not a fan of the Rustification of rsvg, it has created a ton of problems so far - but maybe with GCC 13 having some Rust support, the platform support issue will solve itself, making bootstrapping easier again.

[nanonyme]

Again, this is not about flatpak directly. This is about a project deliverable which we use to build the runtimes. Runtime has XML but it has no icons let alone SVG. I get that this might be useful functionality for apps. For the runtime appstream compose capability it just sucks hours more worth of build time.

[ximion]

Okay, do you maybe have some documentation link so I can see what this SDK build process is about? I'm generally curious as it seems to be different from the frredesktop-sdk at https://gitlab.com/freedesktop-sdk/freedesktop-sdk that has included rsvg for quite a while.

For your problem I think we could allow an AppStream build without rsvg, but I would make it so that you need to explicitly disable SVG support and I'd make compose output an error like "please compile with SVG support" when encountering an SVG icon, so people at least know what the issue is. As long as for your SDK this reduced build of AppStream never encounters any desktop-application, this should not cause issues (and I just looked at the code, the maintenance cost of such a flag seems reasonable).

[nanonyme]

We build runtimes with with Docker images created from freedesktop-sdk components https://gitlab.com/freedesktop-sdk/infrastructure/freedesktop-sdk-docker-images and this contains flatpak and flatpak-builder. As dependency also appstream. We grow support for new arches through qemu-binfmt and building LLVM and Rust on qemu-binfmt just for appstream is quite a lot. It seems perfectly fine to me we would build appstream multiple times, once internally with less deps and once for everyone to use with full deps. We already do this for some other components eg to resolve dependency cycles. I agree, hitting SVG when built without SVG support should result in a hard error.

[ximion]

Ah, I see! It's a container image for building runtimes within. Building a thing multiple times with more and more dependencies is pretty normal.
I think the above patch should solve your issue: It will allow you to disable rsvg temporarily (as soon as AppStream encounters an SVG icon it will complain very loudly!), but still have all the functionality that doesn't depend on SVG support.
If a version of appstream-compose every reaches a system where metadata for GUI components is generated, we'll find out pretty much immediately this way :-)

[nanonyme]

Actually @abderrahim pointed out librsvg might in reality get used (in real usage) through gdk-pixbuf whereas the direct SVG functions seem to only be used by tests.

[ximion]

@nanonyme Sure, but if we try to use it and the GdkPixbuf loader is missing, we will still throw an error. We could probably throw a better error in case AppStream was built with rsvg and we still can't find the pixbuf loader at runtime... (quite possibly a rare issue though).