This amount of breakage (65 packages, *despite* validation), is a sign
of a bigger problem. The "validation" is weak, and the filtering
applied in gnome-software, i.e. the user interface, is strong and
unexpected and silent. IMHO things should be reversed: validation
should be proactive and warn about things which are wrong now or will
be considered wrong in the future, and no filtering should be done
during display.
If there are some issues with an appdata entry, both users and the
package maintainers would be much better served if it is displayed,
even imperfect and ugly, than not at all. It would be much easier to
diagnose things, and would probably encourage more people to fix those
visual issues. Currently it's just too easy to never see the problem.
Filtering in this final "user" stage just seems to be in the wrong
place, and goes against the principle of gentle degradation.
Zbyszek
On Fri, Jan 06, 2017 at 07:26:52PM +0000, Richard Hughes wrote:
> On 6 January 2017 at 02:16, Ben Rosser <rosser.bjr@xxxxxxxxx> wrote:
> > It turns out that I am very silly, and, when writing the appstream
> > file for tilp2, never changed "comical.desktop" in the template here
> > [1] to "tilp.desktop".
> > ...whoops! I can, uh, fix that.
>
> :)
>
> > However, interestingly, it seems that "appstream-util validate-relax
> > --nonet" doesn't seem to care. It happily validates tilp2's appstream
> > information [2], which is why I never noticed this at the time. I
> > would think that "referenced desktop file doesn't exist on system"
> > should at least be a warning or something when validating?
>
> Well, to do a full validation we need to search for the icon, look for
> the desktop file and validate the appdata file. This is what you can
> do with:
>
> $ appstream-util check-root
>
> Although it's best used in the package build system, e.g. for RPM you can do:
>
> DESTDIR=%{buildroot} appstream-util check-root
>
> It's lightly tested, so it if works or breaks please let me know.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
