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
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.
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
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.
On 13 January 2015 at 12:01, Michael Schwendt mschwendt@gmail.com 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
packaging@lists.fedoraproject.org
-
Mario Blättermann -
Michael Schwendt -
Richard Hughes