dev-util/glib-utils: Build time utilities for glib using projects

This package will house a set of utilities split out of dev-libs/glib,
primarily to avoid a runtime dependency on python in dev-libs/glib
itself, for e.g. embedded system purposes. Once the consumers of
these utilities build depend on this and the forced dep in glib
can be dropped, that is.

Initially glib-genmarshal, glib-mkenums and gtester-report are part
of this package, as these require python at runtime.
gdbus-codegen is likely to remain a separate package, as it installs
a bigger python module.
glib-compile-resources might at some point be moved here, as then
we can express its potential runtime dependencies of libxml2:2 and
gdk-pixbuf:2 here, but this is undecided as of yet, and won't happen
before meson is used for building glib.

This commit adds a transitional glib-utils-2.52.3 with stable
keywords for migration purposes. It just pulls in glib itself, which
at that version provides the tools itself. This allows other
packages to start build depending on dev-util/glib-utils right away,
as there will be no wait for stable keywords.

If your package calls glib-genmarshal or glib-mkenums, then please add
a build dependency on dev-util/glib-utils. With meson a good hint of
such usage is the occurrence of "genmarshal" or "mkenums" in any
meson.build file; usually with "gnome." in front, but it depends under
what name the meson gnome module is imported as ("gnome" is the
convention out there).
With autotools a good hint is a direct call to either utility in any
Makefile.am file, however with autotools generated marshallers or
enums are often shipped in release tarballs without a need to
regenerate them, in which case the dependency may be unnecessary.

gtester-report is a deprecated utility to generate HTML reports out
of gtester output. Some packages test phases have a dependency on it,
or a build time check, even if not actually used in relevant make
targets. In such a case it might be more appropriate to shortcut
the check with something like "GTESTER_REPORT=$(type -P true)" instead
of depending on this package, as no-one is going to be looking at those
HTML reports. But sometimes it might be used in default check targets,
which would have to be patched out; so just depending on glib-utils is
a possibility until such a time (or if not worth the effort).

Package-Manager: Portage-2.3.47, Repoman-2.3.10

2 files changed, 26 insertions, 0 deletions

diff --git a/dev-util/glib-utils/glib-utils-2.52.3.ebuild b/dev-util/glib-utils/glib-utils-2.52.3.ebuild
new file mode 100644
index 000000000000..bbc78a7fd93d
--- /dev/null
+++ b/dev-util/glib-utils/glib-utils-2.52.3.ebuild
@@ -0,0 +1,15 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=6
+
+DESCRIPTION="Build utilities for GLib using projects"
+HOMEPAGE="https://www.gtk.org/"
+
+LICENSE="LGPL-2.1+"
+SLOT="0" # /usr/bin utilities that can't be parallel installed by their nature
+IUSE=""
+
+KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 s390 ~sh sparc x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~arm-linux ~x86-linux"
+
+RDEPEND="dev-libs/glib:2"
diff --git a/dev-util/glib-utils/metadata.xml b/dev-util/glib-utils/metadata.xml
new file mode 100644
index 000000000000..0da0d356cb57
--- /dev/null
+++ b/dev-util/glib-utils/metadata.xml
@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
+<pkgmetadata>
+	<maintainer type="project">
+		<email>gnome@gentoo.org</email>
+		<name>Gentoo GNOME Desktop</name>
+	</maintainer>
+	<upstream>
+		<remote-id type="cpe">cpe:/a:gnome:glib</remote-id>
+	</upstream>
+</pkgmetadata>