-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/13/2016 05:32 AM, Alexis Ballier wrote:
> On Mon, 11 Apr 2016 22:04:10 -0400 NP-Hardass
> <np-hard...@gentoo.org> wrote:
>
>> # Inherit happens below after declaration of GNOME2_LA_PUNT
>>
>> # @ECLASS-VARIABLE: MATE_LA_PUNT # @DESCRIPTION: # Available
>> values for MATE_LA_PUNT: # - "no": will not clean any .la files #
>> - "yes": will run prune_libtool_files --modules # - If it is not
>> set, it will run prune_libtool_files # MATE_LA_PUNT is a stub to
>> GNOME2_LA_PUNT GNOME2_LA_PUNT=${MATE_LA_PUNT:-""}
>
>
> any reason for the indirection instead of using directly
> GNOME2_LA_PUNT ?
>
> [...]
>> # @FUNCTION: mate_src_configure # @DESCRIPTION: # MATE specific
>> configure handling # Stub to gnome2_src_configure()
>> mate_src_configure() { gnome2_src_configure }
>>
>> # @FUNCTION: mate_src_install # @DESCRIPTION: # MATE specific
>> install. Stub to gnome2_src_install mate_src_install() {
>> gnome2_src_install }
>>
>> # @FUNCTION: mate_pkg_preinst # @DESCRIPTION: # Finds Icons,
>> GConf and GSettings schemas for later handling in pkg_postinst #
>> Stub to gnome2_pkg_preinst mate_pkg_preinst() {
>> gnome2_pkg_preinst }
>>
>> # @FUNCTION: mate_pkg_postinst # @DESCRIPTION: # Handle
>> scrollkeeper, GConf, GSettings, Icons, desktop and mime #
>> database updates. # Stub to gnome2_pkg_postinst
>> mate_pkg_postinst() { gnome2_pkg_postinst }
>>
>> # @FUNCTION: mate_pkg_postrm # @DESCRIPTION: # Handle
>> scrollkeeper, GSettings, Icons, desktop and mime database
>> updates. # Stub to gnome2_pkg_postrm mate_pkg_postrm() {
>> gnome2_pkg_postrm }
>
> and here too, why not rely on gnome2.eclass exported functions (or
> say gnome2.eclass api is part of mate.eclass api)?
>
The idea was partly due to consistency. Rather than calling mate_this
gnome2_that, it'd provide one namespace. Additionally as mentioned in
my initial email, since GNOME and MATE aren't always in synch, if the
gnome2 eclass chooses to change something, and it's better that mate
eclass stays with what we have, all I have to do is fill in the stub,
and all ebuilds retain their current implementation. Otherwise, I'd
have to mass edit all ebuilds to replace the offending gnome2_ with
mate_. Furthermore, there was a discussion a long time ago about how
functions shouldn't be called without an explicit inherit. That means
that even if the mate eclass uses gnome2, if I opt to call gnome2
directly in the ebuild, I have to explicitly inherit it (which mostly
defeats the purpose of inheriting it in the mate eclass). This has an
added bonus, which is that the gnome2 eclass inherits gnome.org, so I
have to make sure to re-inherit mate-desktop.org whenever gnome2 is
(re)inherited to prevent all of variables like SRC_URI from being
overwritten. Hope that I'm conveying that logic adequately.
- --
NP-Hardass
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXDkHcAAoJEBzZQR2yrxj7s9kQAJIsWD8bIEd6A16ZMCCIbz6M
Usu+JmQGshQjgKyjntkhjWQ3O7pY0IG6yEFbaXOLrt2pDJ3qoabSq2AiEMlJLJ1v
s467fVuEFv4+u50Bza4o2SdD5FD50tnGUOOYLbP8HMHWdOw6qB9o2RbVr+6TU6Ug
KHfErHRAL1TlBKN/MLMFWKC0v+0fBsKcdQeszLvdQwX0Zf2V3/Fw99HhxsdNVYs8
x/xSD2vdh0yA1+CbLx6q/fWKnBWNTIyRvqdtQNyq7BNUwq/46ZjKufksO+hUEBCv
Ai7nxPbOtYvhigRYEYqoSdAmoWxPOgamZGB50P1yiRAyFRI7bPQ5YhQCDflINLLG
59nytNwrZ7xvUKJBdwCeFTjMbG98s1WeFJbbNPDxcWvi9YGuTIa8QHDZt3k9adhH
QSpWeBXDYgWX1Fb+3RQ4J0+gf3uzwNJfMSMkwENJF/FnlDY+MV62XscCuPV4tH5j
39niyqFEmu0v8IWjPdyFY5luyoud+Wxc7+DiFQwh2YamoVV6rwlwtIJVDYaSiHEK
vJqyUvku6egfxzjhmUuKgPdwCXgOuAtTxmv1Yo4vdCP+GGYrINzTZg9V1ez/xAW+
hyUDXZnbqBAS7PDtVkotucB7+kwZV3O43BJ/DyJcDj/kCt309zAViKCMJmO+TWWU
UoFkyP7MGcjxTnY0lyY3
=MC7/
-----END PGP SIGNATURE-----
