Re: [gentoo-dev] [RFC] New eclass: mate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/13/2016 12:19 PM, Alexis Ballier wrote: > On Wed, 13 Apr 2016 08:55:56 -0400 NP-Hardass > wrote: [...] >> 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_. > > yep, makes sense > >> 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). > > nah, this isnt true in your case: you can define mate.eclass' API > to always include gnome2.eclass, making it ok to use gnome2 > functions by inheriting only mate.eclass. this means you can never > drop gnome2.eclass from mate.eclass though, which may not be > desired > I'm unfamiliar with this. Do you have a reference that I can look at? > >> 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. > > ok, maybe you could add a comment that no ebuild should inherit > both gnome2 & mate eclasses then > - -- NP-Hardass -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXDnIUAAoJEBzZQR2yrxj7WLgP/0JoEMUrbc3DjYP2SVpUM5F1 slgblQuY+2ElDpoDIoSU+GY3aSv7kv1WnH8gPRPTOYsW1XSmjXwSVbAeh0s7g8fR 779Kl3aKxHQiaNmSv4wCoBTUO3AXQrC168C13h3PebVnPVUg1df/pILbfR9vAkhR VLL/9A3WVBLb980gywJpiEPWZC7pBIAWdD6jHdhGW9u75k4Q/Ro6jUN+NQYjexr5 S0q0CTkxJw3nJA/K+VxnLltyUoJ7i7V3MoQM4hxebTDxev6ni3rahAK7XU00Itgi r8nAOlBbporrl2pnX/xm6HEZm14oRPo8z9Cm7Te6t7eZODtzIZlnRJkqxVVHPRWN dhO9m8u9FpkpTsTWE2eXX9Xqwx1WLXNWxjrkiGV7urEFLI66x05pMm+JLAoyEMB1 i1ep8DuXOcTaZPQbiPOoSEcdi79pJ9kClwyRyzVCPca/Pz0n23N/OqSNVa2FTCLT BZ5YByFO9iG90qSqCmbbjygjo51yhQJn3WqS1Kmk8N9Pdj314VQI8anWesL8Q6Ua j9+QtIrmZ727DiLELrox/RvZ5nkr2UuO931k3iCeNSTLmhlPBSrNlQIzFL2snwp3 Y0RGgI0QUSc3l/BOP/aPhPTvPgk8JH1zjPRR5tvAPgAMoOU9JcjLDtZA2puNhp+B UchoZyvlfnF+7rOWzcLB =kgsm -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New eclass: mate
On Wed, 13 Apr 2016 08:55:56 -0400 NP-Hardass wrote: [...] > 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_. yep, makes sense > 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). nah, this isnt true in your case: you can define mate.eclass' API to always include gnome2.eclass, making it ok to use gnome2 functions by inheriting only mate.eclass. this means you can never drop gnome2.eclass from mate.eclass though, which may not be desired > 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. ok, maybe you could add a comment that no ebuild should inherit both gnome2 & mate eclasses then
Re: [gentoo-dev] [warning] the bug queue has 82 bugs
On 13/04/16 07:49, Austin English wrote: > On 04/11/2016 04:00 PM, Alex Alexander wrote: > > Our bug queue has 82 bugs! > > If you have some spare time, please help > > assign/sort a few bugs. > > > To view the bug queue, click here: http://bit.ly/m8PQS5 > > Thanks! > I got it down to 6. Enjoy. > > -Austin Austin+++ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New eclass: mate
-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
> 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-
Re: [gentoo-dev] [RFC] New eclass: mate
On Mon, 11 Apr 2016 22:04:10 -0400
NP-Hardass 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)?
