Appdata validation alternative

[Mario Blättermann]

Hi all,

currently we have the following command for appdata validation in the guidelines
[1]:

appstream-util validate-relax --nonet %{buildroot}/%{_datadir}/appdata/*.appdata.xml

This is OK so far and it works... But libappstream-glib (which provides the
appstream-util command) requires gtk3. That's not nice if we package software
based on Qt or any other GUI toolkit. Is there an alternative way to validate
appdata files without pulling in software related to a certain GUI toolkit?

I found already appdata-tools, but that one also depends on libappstream-glib.

[1] http://fedoraproject.org/wiki/Packaging:AppData

Best Regards,
Mario

[Michael Schwendt]

On Mon, 12 Jan 2015 22:04:41 +0100, Mario Blättermann wrote:

>  
>  This is OK so far and it works... But libappstream-glib (which provides the
>  appstream-util command) requires gtk3. That's not nice 
In which way is it "not nice"? Only with regard to the buildroot?
Or do you want to keep your local installation completely free of GTK
(and possibly even GLib?) when rpmbuilding packages without using tools
like Mock?

>  if we package software
>  based on Qt or any other GUI toolkit. Is there an alternative way to validate
>  appdata files without pulling in software related to a certain GUI toolkit? 
Just my opinion on this: I would not worry that much about this. GUI
toolkit wars are silly anyway. And it could even be that around the
appstream stuff not all is carved into stone either.

[Mario Blättermann]

Hi Michael,

Am 13.01.2015 um 08:25 schrieb Michael Schwendt:
>  On Mon, 12 Jan 2015 22:04:41 +0100, Mario Blättermann wrote:
>  
> >
> > This is OK so far and it works... But libappstream-glib (which provides the
> > appstream-util command) requires gtk3. That's not nice
>  
>  In which way is it "not nice"? Only with regard to the buildroot?
>  Or do you want to keep your local installation completely free of GTK
>  (and possibly even GLib?) when rpmbuilding packages without using tools
>  like Mock?
>   
I don't care about additional packages to install on my local system. Well, I
don't use Mock that much, for testing purposes mostly I install packages locally
and finally make sure in Copr or at least on Koji that the build requirements
are present.

But due to we force packagers to validate their appdata files, we pull in GTK3
for all GUI-based packages, regardless of whether they really need GTK3 to
build. That's strange. Imagine, someone wants to rebuild a Qt based package on
his/her local system for some reasons, and GTK is needed therefore. This is
confusing. What about to make the appdata validation conditional, while keeping
it enabled by default?

%global with_appdata_check 1

%check
%if 0%{?with_appdata_check}
appstream-util validate-relax --nonet %{buildroot}/%{_datadir}/appdata/*.appdata.xml
%endif # with_appdata_check

> > if we package software
> > based on Qt or any other GUI toolkit. Is there an alternative way to validate
> > appdata files without pulling in software related to a certain GUI toolkit?
>  
>  Just my opinion on this: I would not worry that much about this. GUI
>  toolkit wars are silly anyway. And it could even be that around the
>  appstream stuff not all is carved into stone either. 
I'm far from initiating yet another flame war regarding the GUI toolkits. On my
KDE system I'm also using GTK3 software, and moreover I even maintain GTK3 packages.

BTW, to simplify the appdata check for us, we could introduce a new macro with
the following content:

%appdata_validate \
appstream-util validate-relax --nonet %{buildroot}/%{_datadir}/appdata/*.appdata.xml

And maybe another macro for the appdata directory:

%_appdatadir %_datadir/appdata

The latter would be strictly independent then from the special directories in
KDE, where we use %_kde4_datadir instead of %_datadir. Well, it is the same
directory for now, but this could change in the future.

This would shorten the spec file and also make sure that the appdata file has
been installed in the correct directory. The macro file
/usr/lib/rpm/macros.appdata should be shipped with libappstream-glib or even
directly with redhat-rpm-config.

Best Regards,
Mario

[Michael Schwendt]

On Tue, 13 Jan 2015 10:54:38 +0100, Mario Blättermann wrote:

>  [...] we force packagers to validate their appdata files, we pull in
> GTK3
>  for all GUI-based packages, regardless of whether they really need GTK3 to
>  build. That's strange. Imagine, someone wants to rebuild a Qt based package on
>  his/her local system for some reasons, and GTK is needed therefore. This is
>  confusing. 
Hyperbole, IMHO.

It doesn't pull in gtk3-devel but just the run-time lib. How does that
confuse anyone? You only need to run the tool not do anything with the GUI
lib.
Other tools pull in other framework/backend libs runtime. desktop-file-validate
pulls in GLib. That's not a GUI lib, but that doesn't mean only "unwanted
GUI libs" are "not nice".

>  What about to make the appdata validation conditional, while keeping
>  it enabled by default? 
$ ldd /usr/bin/appstream-util |wc -l
82
$ ldd /usr/bin/appstream-util |grep -i libx|wc -l
27
$ ldd /usr/bin/appstream-util|grep drm
	libdrm.so.2 => /lib64/libdrm.so.2 (0x00007fdb0ee0b000)

It could be that most of those are just because it relinks with
everything  libappstream-glib.so.1  is linked with already. I doubt
it needs all those lib APIs directly. It would not be the first time
redundant libs are added to the compiler linker options somewhere.

But even then, it's just a tool, and the most one could do is examine
it and link only the stuff it really uses directly. And do the same
for libappstream-glib and similar libs.

-- 
Today you're focused on GTK, tomorrow you would be confused by the
tool also pulling in something else. Not worth it, IMO.

[Richard Hughes]

On 13 January 2015 at 12:01, Michael Schwendt <mschwendt(a)gmail.com&gt; wrote:
>  It could be that most of those are just because it relinks with
>  everything  libappstream-glib.so.1  is linked with already. I doubt
>  it needs all those lib APIs directly. 
libappstream-glib only needs GdkPixbuf (to check the screenshot
sizes), not the whole of GTK.

Richard