Skip to content

its: support metainfo files with set namespace - #777

Open
sp1ritCS wants to merge 1 commit into
ximion:mainfrom
sp1ritCS:metainfo-its-with-namespace
Open

its: support metainfo files with set namespace#777
sp1ritCS wants to merge 1 commit into
ximion:mainfrom
sp1ritCS:metainfo-its-with-namespace

Conversation

@sp1ritCS

Copy link
Copy Markdown

Match libappstream and only operate on the local name, irrespective of actually set namespace.

Kinda nasty, but sadly necessary when having to deal with namespaced and namespaceless files :/.

Match libappstream and only operate on the local name, irrespective of
actually set namespace.
@ximion

ximion commented Aug 12, 2026

Copy link
Copy Markdown
Owner

There is no namespace for AppStream Metadata that we defined - so shouldn't we rather make that namespaced stuff fail validation and reject it outright? Either that, or we do officially define a namespace, but until we do that, I think we should just reject namespaced data, since it is not compliant with the specification (which, while not explicitly forbidding namespaces, does not name one and has no example of using one).

@sp1ritCS

Copy link
Copy Markdown
Author

I know that using a namespace is 'discouraged', but the way I understand the manual, adding xmlns="https://specifications.freedesktop.org/metainfo/1.0" is allowed.

@ximion

ximion commented Aug 12, 2026

Copy link
Copy Markdown
Owner

Right, I forgot we added that... It is not at all a great idea in pretty much all cases, and I am not even sure it validates correctly, since absolutely nobody tests this.

Why do you need a namespace? Why can't you just drop it?

@sp1ritCS

Copy link
Copy Markdown
Author

I am not even sure it validates correctly

It does, since libappstream really only ever gets the name of the node trough xmlNodes name member, which is just the local name, so it ignores whatever (if any) namespace is set on the nodes.

Why do you need a namespace?

The application manifests gtk-android-builder operates on, are expected to embed an appstream manifest within /pw:app/pw:metainfo, typically by XIncluding the already existing appstream manifest of the application. As the pixiewood manifests have a namespace, embedding the appstream manifest within them without them setting their own namespace results them being tagged as part of the pixiewood namespace (or not if the manifest uses xmlns:pw="..." instead of xmlns="...").

I did originally implement it that way instead of the other way around (pixiewood information within appstream custom tags), due to the custom tags not being flexible enough for storing the multi-layer application icons and by now the pixiewood manifests contain stuff that really shouldn't be part of the appstream manifest (configure options, etc.)

@sp1ritCS

sp1ritCS commented Aug 17, 2026

Copy link
Copy Markdown
Author

The metainfo.its shipped as part of GNU gettext has essentially all its rules duplicated, one set with the https://specifications.freedesktop.org/metainfo/1.0 namespace and one without: https://github.com/git-for-windows/git-sdk-64/blob/main/mingw64/share/gettext-1.0/its/metainfo.its (can't link to upstream due to both their cvsweb and cgit being down)

While this technically doesn't match what libappstream is doing, that approach would work for me too, should you prefer it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants