Appstream does no handle <component type="shell-extension">

[StefanBruens]

libappstream-glib defines some additional component types, see
https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-app.h#L319

This causes some errors when appstream(cli) encounters such entries:

** (appstreamcli:9324): DEBUG: 03:54:39.820: WARNING: Ignored component 'launch-new-instance_gnome-shell-extensions.gcampax.github.com': The component is invalid.

[ximion]

@StefanBruens This is a bug in appstream-glib for implementing a non-standard extensions. What asglib thinks is its own component type should actually be a component of type "addon" extending the org.gnome.Shell component.

So I am inclined to just close the issue.
@hughsie Is there anything you can do on the asglib side? Is it sensible to drop that component type, or at least print a fat warning of someone uses it?

[hughsie]

Is it sensible to drop that component type

No, we're shipping this in RHEL 7 and so I have to support it at least for the next 10 years...

I agree it should be an addon to org.gnome.Shell, but that fallback code isn't written either in the generator or the client tools.

On a more general note, isn't this supposed to be XML? It doesn't feel very extensible if every unknown tag value or attr is being flagged as a warning...

[ximion]

@hughsie For the general note: This is AppStream and I want it to be validated strictly. It's XML, so you can add new tags if you want to, but making completely invalid components will always yield a warning - otherwise stuff will go missing in software centers without us knowing what happened, or even that there is stuff missing.
A valid AppStream component has the minimal requirements of:

1. Have an ID
2. Have a valid component type (can be generic or empty)
3. Have a unlocalized name
4. Have a unlocalized summary

That being said, when validating metadata (not just loading it), even unknown tags (that aren't prefixed with a different XML namespace or x-) will yield a warning, so typos can be caught.

[ximion]

For the RHEL case: Don't you only need to maintain an older series for RHEL, so any new releases can make changes? Otherwise, software development would not move forward because every new version still has to support the featureset that any older version had in RHEL once.