Hello Ingo,
On Monday, 21 June 2021 22:55:03 CEST, Ingo Klöcker wrote:
I thought, I'd ask you, because you have updated the AppData files of
Kleopatra a few times. Building the flatpak of Kleopatra failed with the
error:
Not entirely by myself, this is scripted as the part of the release process
of KDE Gear [1][2].
```
Running appstream-compose
Processing application org.kde.kleopatra
org.kde.kleopatra.desktop: AppData problem: tag-invalid : <release>
version was duplicated
Error loading AppData file: AppData file /app/share/appdata/
org.kde.kleopatra.appdata.xml was not valid
```
[...]
appstream-compose does not seem to like multiple <release> tags
with identical
version properties. I checked the AppStream specs at
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-releases
but there is no requirement that different <release> tags have different
version properties. In fact, the version property seems to be optional.
Do you know whether the AppStream file of Kleopatra is invalid or whether
appstream-compose is wrong in requiring different version properties for
different <release> tags?
I read the spec the same way you do and appstreamcli validate --pedantic
validates the file successfully. But leaving that aside I don't think that
the expectation that a release (identified by a version) only has one date
is unreasonable. I can't say much about flatpak as such, but I'm forwarding
this to the release-team ML, which may have more knowledgeable people.
Besides that, I can think of a few ways to fix this.
1) Indicate for the scripts to skip kleopatra
2) Change the scripts to not add duplicate versions
3) Change the version manually before every release of KDE gear
4) Adopt the RELEASE_SERVICE_VERSION scheme
1) is probably bad because distros want appstream metadata with versions,
and I think flatpak especially insists upon that as well, although it
obviously still could be added manually. 2) would show somewhat confusing
information.
3) would work, but obviously needs someone to remember to do that. 4) would
basically do that by yet another script running during the release process.
It would also make automatically adding bugzilla versions work and, more
importantly, would allow users to differentiate between releases. It's also
what our guideline on the topic suggests [3].
Regards,
Heiko
[1]
https://invent.kde.org/sysadmin/release-tools/-/blob/master/add_appstream_versions.sh
[2] https://invent.kde.org/sysadmin/appstream-metainfo-release-update
[3] https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning
