Require homepage URL

[barthalion]

appstream-glib enforces homepage URL presence: https://github.com/hughsie/appstream-glib/blob/d26446e437c9b82f3267ca22874f86f4a1954638/libappstream-glib/as-app-validate.c#L1823

I think it's a reasonable requirement to implement also here. While we can unroll rDNS to build a fake homepage URL, not all developers actually host a proper website.

[ximion]

Not a bad idea... A lot of stuff was optional in the past to make people adopt the spec easier, but we can really tighten some requirements now, I think.
And most stuff should have a homepage, even generic components and runtimes might have one (although for those I wouldn't make a missing homepage fatal).

[barthalion]

Obviously we primarily care about desktop-applications and console-applications, but this seems to have been outright required for everything in appstream-glib.

[ximion]

I very much care for firmware, drivers and generic components as well - but they all should actually have homepages :-)
It's a fairly easy requirement to fulfill (I ran some tests, and most components already do so).

[ximion]

It's a fairly easy requirement to fulfill

Hah! In hindsight, making this a warning right away (and not following the usual info -> warning after 6-12 months process) was a pretty bad call, as I was made aware by KDE ^^

Next time, it's probably best to introduce a new check here at a low severity and have Flathub raise it (and only make AppStream raise it too after some time has passed).

[bbhtt]

as I was made aware by KDE

Can you please point to what issues they have? Flathub never patched this check in as-glib so pretty much all apps on Flathub should already have this tag and most of the KDE apps (around ~150) are on Flathub and they come from upstream, meaning by extension, everything upstream and also on Flathub, should also have it?

[ximion]

4 people contacted me separately today that it apparently broke their CI as many components didn't have it. Compounding the issue was apparently some unrelated change by automation, breaking the MetaInfo data further, so people were extremely unhappy.
But @aleixpol knows more I guess. Next time we need to be more careful with introducing new warnings for existing tags... (usually I run new validation changes against the entire Debian archive to get some idea about the impact, but I didn't do it for this change because I also just assumed that every component that's not generic for sure must have had a homepage associated already - grave mistake :-p)

[svuorela]

Can you please point to what issues they have? Flathub never patched this check in as-glib so pretty much all apps on Flathub should already have this tag and most of the KDE apps (around ~150) are on Flathub and they come from upstream, meaning by extension, everything upstream and also on Flathub, should also have it?

I think the number of KDE apps is closer to 500 than 150, so 'most' is quite an exaggeration. Some of them only for the workspace offering (and thus not likely flatpak'ed). Other failing ones were the more fringe apps.

[bbhtt]

is closer to 500 than 150, so 'most' is quite an exaggeration.

Never knew... apps.kde.org lists much less than that and none of the distros I've seen/used packages all of them. It's very hard to judge the impact in cases like this.

I guess it's fine if @ximion wants to do a point release and reduce it to info. We can always raise it or keep the default depending on the situation at flathub.

[barthalion]

Maybe warnings should be treated as errors, too…

[svuorela]

is closer to 500 than 150, so 'most' is quite an exaggeration.

Never knew... apps.kde.org lists much less than that and none of the distros I've seen/used packages all of them. It's very hard to judge the impact in cases like this.

Debian doesn't package everything, but including Qt (around 20 sources) and KDE's libraries (around 100), the Debian people have 520 upstream sources.

But even 5% is annoyingly much in that case.

I guess it's fine if @ximion wants to do a point release and reduce it to info. We can always raise it or keep the default depending on the situation at flathub.

I think most things have been fixed for the homepage url by now while ranting about appstream. But please be much more careful going forward.

[bbhtt]

Debian doesn't package everything, but including Qt (around 20 sources) and KDE's libraries (around 100)

Are we talking about libraries with metainfo files? Can you provide some examples of things that broke?

[svuorela]

Debian doesn't package everything, but including Qt (around 20 sources) and KDE's libraries (around 100)

Are we talking about libraries with metainfo files? Can you provide some examples of things that broke?

sorry. I was unclear. I was trying to guess that debian seems to have 400-ish kde-ish non-library packages. But all of the workspace specific things might still have appstream files, but shouldn't be on flathub.

[ximion]

This warning is not emitted for language packs and libraries though - but it appears like many of the affected components are of addon-type, so, plugins.
(it would be neat if more libraries had the metadata, it makes it very easy to find out what systems are comprised of)

At this point the ship has sailed and reducing the priority doesn't make sense anymore (as people adjusted their data), but in future we need to be a bit more careful when touching widely-used tags.

Maybe warnings should be treated as errors, too…

They are! The severities roughly assigned like this: Errors are gross spec violations or make the data completely unusable, warnings result in degraded data (parts may be ignored, unintended consequences may happen), but generally we can salvage stuff - many warnings are minor spec violations (e.g. style-based requirements), and some can be overridden to a lower priority if a project thinks they are unwarranted (unlike errors, which can not be touched). Infos are problems that would be nice to have fixed, some may become warnings in future (stuff like URLs not being HTTPS for example, or more minor style issues). Pedantic issues are nice-to-have and could improve metadata, but are safe to be totally ignored.
The first two categories make a validation fail.

[bbhtt]

This warning is not emitted for language packs and libraries though - but it appears like many of the affected components are of addon-type, so, plugins.

This might have been problematic even on Flathub but most stuff that'll use type addon are flatpak extensions and fortunately validation is skipped for them.