Re: [gentoo-dev] [RFC] New eclass: mate

2016-07-01 Thread Michał Górny 
On Tue, 14 Jun 2016 22:56:12 -0400
NP-Hardass  wrote:

> diff --git a/eclass/mate-desktop.org.eclass b/eclass/mate-desktop.org.eclass
> index 5f92c4f..c57528d 100644
> --- a/eclass/mate-desktop.org.eclass
> +++ b/eclass/mate-desktop.org.eclass
> @@ -12,22 +12,16 @@
>  # Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well as
>  # exporting some useful values like the MATE_BRANCH
>  
> -# Old EAPIs are banned.
> -case "${EAPI:-0}" in
> - 5|6) ;;
> - *) die "EAPI=${EAPI} is not supported" ;;
> -esac
> +# EAPIs < 6 are banned.
> +if [[ "${EAPI:-0}" != "6" ]]; then
> + die "EAPI=${EAPI:-0} is not supported"
> +fi

case is recommended to make adding EAPIs easier.

> diff --git a/eclass/mate.eclass b/eclass/mate.eclass
> index a0209bf..074ed8d 100644
> --- a/eclass/mate.eclass
> +++ b/eclass/mate.eclass
> @@ -15,10 +15,9 @@
>  # fact that MATE is a GNOME fork. For additional functions, see 
> gnome2-utils.eclass.
>  
>  # Check EAPI only
> -case "${EAPI:-0}" in
> - 5|6) ;;
> - *) die "EAPI=${EAPI} is not supported" ;;
> -esac
> +if [[ "${EAPI:-0}" != "6" ]]; then
> + die "EAPI=${EAPI:-0} is not supported"
> +fi

Likewise.

>  
>  # Inherit happens below after declaration of GNOME2_LA_PUNT
>  
> @@ -33,20 +32,19 @@ GNOME2_LA_PUNT=${MATE_LA_PUNT:-""}
>  
>  inherit gnome2 autotools mate-desktop.org
>  
> -case "${EAPI:-0}" in
> - 5|6)
> - EXPORT_FUNCTIONS src_prepare src_configure src_install 
> pkg_preinst pkg_postinst pkg_postrm
> - ;;
> - *) die "EAPI=${EAPI} is not supported" ;;
> -esac
> +if [[ "${EAPI:-0}" == "6" ]]; then
> + EXPORT_FUNCTIONS src_prepare src_configure src_install pkg_preinst 
> pkg_postinst pkg_postrm
> +fi

Why the conditional? It can't have any other value at this point.

I will try to find some time to review the whole thing again
in the next 30 days ;-).

-- 
Best regards,
Michał Górny



pgpxmRUXHwH1o.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-15 Thread Michał Górny 
Dnia 15 czerwca 2016 06:18:31 CEST, Jason Zaman  
napisał(a):
>On Fri, Jun 10, 2016 at 12:52:34PM -0400, NP-Hardass wrote:
>> On 06/09/2016 11:54 PM, Jason Zaman wrote:
>> > On Thu, Jun 09, 2016 at 08:19:43AM -0400, NP-Hardass wrote:
>> >> # @FUNCTION: python_cond_func_wrap
>> >> # @DESCRIPTION: Wraps a function for conditional python use, to
>run for each
>> >> # python implementation in the build directory.
>> >> python_cond_func_wrap() {
>> >>   if use python; then
>> >>   python_foreach_impl run_in_build_dir "$@"
>> >>   else
>> >>   $@
>> >>   fi
>> >> }
>> > 
>> > I dont see where you inherited the python eclasses? You also
>probably
>> > need to use use_if_iuse (from eutils.eclass) instead since it seems
>like
>> > python might not be in all the ebuilds. Afaik, you're not allowed
>to
>> > call use foo if foo is not in IUSE already
>> I forgot to include a comment in the ebuild, but the intention was
>that
>> the eclass would not inherit python, by design, those wanting to use
>> that should inherit python themselves.  Although, if I should check
>that
>> explicitly, I am unaware of how to do so, and would appreciate advice
>> from someone, if it is possible. I am aware of INHERITED, but the PMS
>> says it shouldn't be exported to ebuilds, so I'm unsure if/how it
>could
>> be used.
>> 
>> My hope was that since this is used several times (though, not too
>> many), that I could move this logic into the eclass, but if it would
>be
>> more appropriate to just keep that in each of those ebuilds, I can do
>> that too.
>
>Yeah sounds like keeping this in the eclass is right. Moving duplicated
>code into the ebuilds would be a waste. You are defining the API so
>requiring the ebuild to inherit itself is completely okay. I would add
>a
>little more to the doc above to make it super obvious tho.
>
>I don't know how to check if the python eclasses specifically are
>inherited. I think "python" being in IUSE would be sufficient to check
>tho. so all you'd need to do is inherit eutils and replace the "if use
>python" with "if use_if_iuse python".
>
>If you *really* wanted to check you could perhaps do
>if [[ $(type python_foreach_impl) == function ]]. Seems overkill and I
>wouldn't bother. Having python in iuse is probably enough of a sanity
>check.

You can check for the include guards. This is how python-r1 eclasses detect one 
another (in order to prevent inheriting multiple of them).

However, note that all fancy checks are allowed in phase scope only, and not in 
global scope.

>
>-- Jason


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-14 Thread Jason Zaman 
On Fri, Jun 10, 2016 at 12:52:34PM -0400, NP-Hardass wrote:
> On 06/09/2016 11:54 PM, Jason Zaman wrote:
> > On Thu, Jun 09, 2016 at 08:19:43AM -0400, NP-Hardass wrote:
> >> # @FUNCTION: python_cond_func_wrap
> >> # @DESCRIPTION: Wraps a function for conditional python use, to run for 
> >> each
> >> # python implementation in the build directory.
> >> python_cond_func_wrap() {
> >>if use python; then
> >>python_foreach_impl run_in_build_dir "$@"
> >>else
> >>$@
> >>fi
> >> }
> > 
> > I dont see where you inherited the python eclasses? You also probably
> > need to use use_if_iuse (from eutils.eclass) instead since it seems like
> > python might not be in all the ebuilds. Afaik, you're not allowed to
> > call use foo if foo is not in IUSE already
> I forgot to include a comment in the ebuild, but the intention was that
> the eclass would not inherit python, by design, those wanting to use
> that should inherit python themselves.  Although, if I should check that
> explicitly, I am unaware of how to do so, and would appreciate advice
> from someone, if it is possible. I am aware of INHERITED, but the PMS
> says it shouldn't be exported to ebuilds, so I'm unsure if/how it could
> be used.
> 
> My hope was that since this is used several times (though, not too
> many), that I could move this logic into the eclass, but if it would be
> more appropriate to just keep that in each of those ebuilds, I can do
> that too.

Yeah sounds like keeping this in the eclass is right. Moving duplicated
code into the ebuilds would be a waste. You are defining the API so
requiring the ebuild to inherit itself is completely okay. I would add a
little more to the doc above to make it super obvious tho.

I don't know how to check if the python eclasses specifically are
inherited. I think "python" being in IUSE would be sufficient to check
tho. so all you'd need to do is inherit eutils and replace the "if use
python" with "if use_if_iuse python".

If you *really* wanted to check you could perhaps do
if [[ $(type python_foreach_impl) == function ]]. Seems overkill and I
wouldn't bother. Having python in iuse is probably enough of a sanity
check.

-- Jason

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-14 Thread NP-Hardass 
Here's a diff of the changes based on feedback from this ML, followed by
the full eclasses.

Once again, thanks for all the feedback.

-- 
NP-Hardass


diff --git a/eclass/mate-desktop.org.eclass b/eclass/mate-desktop.org.eclass
index 5f92c4f..c57528d 100644
--- a/eclass/mate-desktop.org.eclass
+++ b/eclass/mate-desktop.org.eclass
@@ -12,22 +12,16 @@
 # Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well as
 # exporting some useful values like the MATE_BRANCH

-# Old EAPIs are banned.
-case "${EAPI:-0}" in
-   5|6) ;;
-   *) die "EAPI=${EAPI} is not supported" ;;
-esac
+# EAPIs < 6 are banned.
+if [[ "${EAPI:-0}" != "6" ]]; then
+   die "EAPI=${EAPI:-0} is not supported"
+fi

 if [[ ${PV} ==  ]]; then
inherit git-r3
-else
-   inherit versionator
 fi

-# Ensure availibility of xz-utils on old EAPIs
-if [[ "${EAPI:-0}" -lt "6" ]]; then
-   DEPEND="app-arch/xz-utils"
-fi
+inherit versionator

 # @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX
 # @INTERNAL
@@ -52,11 +46,7 @@ fi
 # @DESCRIPTION:
 # Major and minor numbers of the version number, unless live.
 # If live ebuild, will be set to ''.
-if [[ ${PV} ==  ]]; then
-   : ${MATE_BRANCH:=}
-else
-   : ${MATE_BRANCH:=$(get_version_component_range 1-2)}
-fi
+: ${MATE_BRANCH:=$(get_version_component_range 1-2)}

 # Set SRC_URI or EGIT_REPO_URI based on whether live
 if [[ ${PV} ==  ]]; then
@@ -72,6 +62,3 @@ fi

 # Set HOMEPAGE for all ebuilds
 HOMEPAGE="http://mate-desktop.org;
-
-# Set default SLOT for all ebuilds
-SLOT="0"
diff --git a/eclass/mate.eclass b/eclass/mate.eclass
index a0209bf..074ed8d 100644
--- a/eclass/mate.eclass
+++ b/eclass/mate.eclass
@@ -15,10 +15,9 @@
 # fact that MATE is a GNOME fork. For additional functions, see
gnome2-utils.eclass.

 # Check EAPI only
-case "${EAPI:-0}" in
-   5|6) ;;
-   *) die "EAPI=${EAPI} is not supported" ;;
-esac
+if [[ "${EAPI:-0}" != "6" ]]; then
+   die "EAPI=${EAPI:-0} is not supported"
+fi

 # Inherit happens below after declaration of GNOME2_LA_PUNT

@@ -33,20 +32,19 @@ GNOME2_LA_PUNT=${MATE_LA_PUNT:-""}

 inherit gnome2 autotools mate-desktop.org

-case "${EAPI:-0}" in
-   5|6)
-   EXPORT_FUNCTIONS src_prepare src_configure src_install 
pkg_preinst
pkg_postinst pkg_postrm
-   ;;
-   *) die "EAPI=${EAPI} is not supported" ;;
-esac
+if [[ "${EAPI:-0}" == "6" ]]; then
+   EXPORT_FUNCTIONS src_prepare src_configure src_install pkg_preinst
pkg_postinst pkg_postrm
+fi

 # Autotools requires our MATE m4 files
 DEPEND=">=mate-base/mate-common-${MATE_BRANCH}"

-# @FUNCTION: python_cond_func_wrap
+# @FUNCTION: mate_py_cond_func_wrap
 # @DESCRIPTION: Wraps a function for conditional python use, to run for
each
 # python implementation in the build directory.
-python_cond_func_wrap() {
+# This function should only be used if the ebuild also inherits the
+# python-r1 eclass
+mate_py_cond_func_wrap() {
if use python; then
python_foreach_impl run_in_build_dir "$@"
else
@@ -60,7 +58,7 @@ python_cond_func_wrap() {
 # - true: will always run eautoreconf
 # - false: will default to automatic detect
 # - If it is not set, it will default to false
-FORCE_AUTORECONF=${FORCE_AUTORECONF:-""}
+: ${MATE_FORCE_AUTORECONF:="false"}

 # @FUNCTION: ematedocize
 # @DESCRIPTION: A wrapper around mate-doc-common
@@ -85,8 +83,8 @@ want_mate_doc() {
 mate_src_prepare() {
debug-print-function ${FUNCNAME} "$@"

-   local force_autoreconf=${FORCE_AUTORECONF:-false}
-   [[ ${PV} ==  ]] && force_autoreconf=true
+   local force_autoreconf=${MATE_FORCE_AUTORECONF}
+   [[ ${PV} ==  ]] && force_autoreconf="true"

gen_chksum() {
find '(' -name 'Makefile.am' \
@@ -99,8 +97,8 @@ mate_src_prepare() {

gnome2_src_prepare "$@"

-   if ${force_autoreconf} || [[ ${chksum} != $(gen_chksum) ]]; then
-   [[ want_mate_doc ]] && ematedocize
+   if [[ "${force_autoreconf}" == "true" ]] || [[ ${chksum} !=
$(gen_chksum) ]]; then
+   want_mate_doc && ematedocize
eautoreconf
fi
 }




mate-desktop.org.eclass


# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: mate-desktop.org.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass  based upon the gnome.org
eclass.
# @BLURB: Helper eclass for mate-desktop.org hosted archives
# @DESCRIPTION:
# Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well as
# exporting some useful values like the MATE_BRANCH

# EAPIs < 6 are banned.
if [[ "${EAPI:-0}" != "6" ]]; then
die "EAPI=${EAPI:-0} is not supported"
fi

if [[ ${PV} ==  ]]; then
inherit git-r3
fi

inherit versionator

#

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-10 Thread Michał Górny 
On Fri, 10 Jun 2016 12:52:46 -0400
NP-Hardass  wrote:

> On 06/10/2016 09:33 AM, Michał Górny wrote:
> > On Thu, 9 Jun 2016 08:19:43 -0400
> > NP-Hardass  wrote:
> >   
> >> # Ensure availibility of xz-utils on old EAPIs
> >> if [[ "${EAPI:-0}" -lt "6" ]]; then
> >>DEPEND="app-arch/xz-utils"
> >> fi  
> > 
> > One more thing. What is the rationale for this? I've tried hard, and I
> > can't find anything EAPI-conditional about dependency on xz-utils.
> >   
> 
> There was a light discussion last time I posted this which resulted in
> the suggestion that it be included with EAPI 5.  There were a lot of
> mixed opinions, and a lot of doubts one way or the other.  Should be
> moot now though, as I think I'm going to follow through on perfinion's
> suggestion starting with EAPI 6 only.

Just to be clear, xz-utils situation is the same in all EAPIs. if you
want to be a good person, explicitly depend on it. But it's not
strictly necessary anymore since someone added it to @system out of
laziness.

-- 
Best regards,
Michał Górny



pgpD6gsXY15lw.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-10 Thread Michał Górny 
On Fri, 10 Jun 2016 12:52:40 -0400
NP-Hardass  wrote:

> On 06/10/2016 06:43 AM, Michał Górny wrote:
> > Dnia 9 czerwca 2016 14:19:43 CEST, NP-Hardass  
> > napisał(a):  
> >>DEPEND="app-arch/xz-utils"
> >> fi
> >>
> >> # @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX
> >> # @INTERNAL
> >> # @DESCRIPTION:
> >> # All projects hosted on mate-desktop.org provide tarballs as tar.xz.
> >> # Undefined in live ebuilds.
> >> [[ ${PV} !=  ]] && : ${MATE_TARBALL_SUFFIX:="xz"}  
> > 
> > You should ask upstream to supply .tar.lz instead, so they don't harm their 
> > users.
> >   
> I can ask, but I don't think I understand what you mean by "harm their
> users."

It's an internal joke. But I can't find the reference quote right now.

> >> # @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PN
> >> # @DESCRIPTION:
> >> # Name of the package as hosted on mate-desktop.org.
> >> # Leave unset if package name matches PN.
> >> : ${MATE_DESKTOP_ORG_PN:=$PN}
> >>
> >> # @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PV
> >> # @DESCRIPTION:
> >> # Package version string as listed on mate-desktop.org.
> >> # Leave unset if package version string matches PV.
> >> : ${MATE_DESKTOP_ORG_PV:=$PV}
> >>
> >> # @ECLASS-VARIABLE: MATE_BRANCH
> >> # @DESCRIPTION:
> >> # Major and minor numbers of the version number, unless live.
> >> # If live ebuild, will be set to ''.
> >> if [[ ${PV} ==  ]]; then
> >>: ${MATE_BRANCH:=}
> >> else
> >>: ${MATE_BRANCH:=$(get_version_component_range 1-2)}
> >> fi  
> > 
> > Unless I'm missing something, the 1-2 range will return  in live 
> > version as well. Unless you are trying to avoid the inherit in the live 
> > ebuild -- then I don't think it's worth the extra code.
> >   
> I will double check and reply again if it is different, but I believe
> the concern had been that if there was a major change in a , and I
> temporarily revbumped the  to -r1, the 1-2 range would return
> -r1 rather then the expected .

Errr, but PV shouldn't contain '-r1'...

> >> # Set SRC_URI or EGIT_REPO_URI based on whether live
> >> if [[ ${PV} ==  ]]; then
> >>EGIT_REPO_URI="
> >>https://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
> >>git://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
> >>http://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git  
> > 
> > Does github actually support http?
> >   
> git clone works, though, I'm unsure if it is redirecting to https.  I'll
> have to double check on this.

Please let me know what you find out.

> >> case "${EAPI:-0}" in
> >>5|6)
> >>EXPORT_FUNCTIONS src_prepare src_configure src_install 
> >> pkg_preinst
> >> pkg_postinst pkg_postrm
> >>;;
> >>*) die "EAPI=${EAPI} is not supported" ;;  
> > 
> > It is already dead after the first check.
> >   
> If I drop EAPI 5 as suggested by perfinion, would you recommend keeping
> this in a case statement for when future EAPIs are added?

No, you can add a case when you need it.

> >> }
> >>
> >> # @FUNCTION: mate_src_prepare
> >> # @DESCRIPTION:
> >> # Call gnome2_src_prepare to handle environment setup and patching,
> >> then
> >> # call eautoreconf if necessary
> >> mate_src_prepare() {
> >>debug-print-function ${FUNCNAME} "$@"
> >>
> >>local force_autoreconf=${FORCE_AUTORECONF:-false}
> >>[[ ${PV} ==  ]] && force_autoreconf=true
> >>
> >>gen_chksum() {
> >>find '(' -name 'Makefile.am' \
> >>-o -name 'configure.ac' \
> >>-o -name 'configure.in' ')' \
> >>-exec cksum {} + | sort -k2
> >>}
> >>
> >>local chksum=$(gen_chksum)
> >>
> >>gnome2_src_prepare "$@"
> >>
> >>if ${force_autoreconf}  
> > 
> > Don't execute random user-provided data.
> >   
> Not sure I understand.  force_autoreconf is a local variable that is
> either when the ebuild explicitly says "I want to eautoreconf," when it
> is a , as upstream does not provide configured sources in git, or
> when patching affects the build system, requiring an autoreconf.

But you shouldn't do it the PHP way. Parse the value, not execute it.
If one does FORCE_AUTORECONF=1, it won't work. If one does
FORCE_AUTORECONF='rm -rf /', it won't work!

-- 
Best regards,
Michał Górny



pgpi68Ykf9Zig.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-10 Thread NP-Hardass 
On 06/10/2016 09:33 AM, Michał Górny wrote:
> On Thu, 9 Jun 2016 08:19:43 -0400
> NP-Hardass  wrote:
> 
>> # Ensure availibility of xz-utils on old EAPIs
>> if [[ "${EAPI:-0}" -lt "6" ]]; then
>>  DEPEND="app-arch/xz-utils"
>> fi
> 
> One more thing. What is the rationale for this? I've tried hard, and I
> can't find anything EAPI-conditional about dependency on xz-utils.
> 

There was a light discussion last time I posted this which resulted in
the suggestion that it be included with EAPI 5.  There were a lot of
mixed opinions, and a lot of doubts one way or the other.  Should be
moot now though, as I think I'm going to follow through on perfinion's
suggestion starting with EAPI 6 only.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-10 Thread NP-Hardass 
On 06/09/2016 11:54 PM, Jason Zaman wrote:
> On Thu, Jun 09, 2016 at 08:19:43AM -0400, NP-Hardass wrote:
>> # Old EAPIs are banned.
>> case "${EAPI:-0}" in
>>  5|6) ;;
>>  *) die "EAPI=${EAPI} is not supported" ;;
>> esac
> 
> How reasonable would it be to ban EAPI5 as well? This is a new eclass so
> it may be better to just take the time to go to EAPI6 directly and not
> have to migrate 5->6 later on.
> 
> 
Would be quite reasonable.  I thought since all the existing MATE
ebuilds are EAPI 5 or 6, it'd be wise to support both, but I've only
actually used (and probably will only use) the eclass with EAPI6 ebuilds.
>> # @FUNCTION: python_cond_func_wrap
>> # @DESCRIPTION: Wraps a function for conditional python use, to run for each
>> # python implementation in the build directory.
>> python_cond_func_wrap() {
>>  if use python; then
>>  python_foreach_impl run_in_build_dir "$@"
>>  else
>>  $@
>>  fi
>> }
> 
> I dont see where you inherited the python eclasses? You also probably
> need to use use_if_iuse (from eutils.eclass) instead since it seems like
> python might not be in all the ebuilds. Afaik, you're not allowed to
> call use foo if foo is not in IUSE already
I forgot to include a comment in the ebuild, but the intention was that
the eclass would not inherit python, by design, those wanting to use
that should inherit python themselves.  Although, if I should check that
explicitly, I am unaware of how to do so, and would appreciate advice
from someone, if it is possible. I am aware of INHERITED, but the PMS
says it shouldn't be exported to ebuilds, so I'm unsure if/how it could
be used.

My hope was that since this is used several times (though, not too
many), that I could move this logic into the eclass, but if it would be
more appropriate to just keep that in each of those ebuilds, I can do
that too.
> 
> Also I'm not sure if having functions start with python_ could lead to
> conflicts later on with the python eclasses?
Yeah, I should probably adjust the namespace
> 
> Other than these minor things, look good!
> -- Jason
> 
> 
Thanks for taking the time to look it over and review.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-10 Thread NP-Hardass 
On 06/10/2016 06:43 AM, Michał Górny wrote:
> Dnia 9 czerwca 2016 14:19:43 CEST, NP-Hardass  
> napisał(a):
>> Greetings all,
>>
>> Sorry for the delay, had lots of recurrent hardware issues the last
>> month or so.
>> I will be adding this to the MATE project repo after I get your
>> feedback, and then into Gentoo repo after I've had some users test out
>> the new packages/eclass.
>>
>> Just a reminder/summary:
>> There are 40-50 ebuilds in the MATE desktop environment, with a fair
>> bit
>> of overlap in the ebuild code, so I thought it best to create an eclass
>> to handle that.  MATE is a fork of GNOME 2 so I used the gnome.org
>> eclass as a reference for the mate-desktop.org eclass.  Additionally,
>> there is much in MATE that is still very much in line with the gnome2
>> eclass.  Rather than having to edit 40-50 ebuilds if we become
>> divergent, I thought it more purdent to just create a separete mate_*
>> namespace. For functions that are currently equivalent, my phase
>> functions are stubs to the gnome2 phase functions.
>>
>>
>> Thanks for taking the time to look these over and give your feedback.
>> (Also, apologies for the thrown together email, I was having trouble
>> getting git-send working to the mailing list)
>>
>> --
>> NP-Hardass
>>
>> ###
>> mate-desktop.org.eclass
>> ###
>>
>>
>> # Copyright 1999-2016 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Id$
>>
>> # @ECLASS: mate-desktop.org.eclass
>> # @MAINTAINER:
>> # m...@gentoo.org
>> # @AUTHOR:
>> # Authors: NP-Hardass  based upon the gnome.org
>> eclass.
>> # @BLURB: Helper eclass for mate-desktop.org hosted archives
>> # @DESCRIPTION:
>> # Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well
>> as
>> # exporting some useful values like the MATE_BRANCH
>>
>> # Old EAPIs are banned.
>> case "${EAPI:-0}" in
>>  5|6) ;;
>>  *) die "EAPI=${EAPI} is not supported" ;;
>> esac
>>
>> if [[ ${PV} ==  ]]; then
>>  inherit git-r3
>> else
>>  inherit versionator
>> fi
>>
>> # Ensure availibility of xz-utils on old EAPIs
>> if [[ "${EAPI:-0}" -lt "6" ]]; then
> 
> EAPI is not a number and must not be treated like a number.
> 
>>  DEPEND="app-arch/xz-utils"
>> fi
>>
>> # @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX
>> # @INTERNAL
>> # @DESCRIPTION:
>> # All projects hosted on mate-desktop.org provide tarballs as tar.xz.
>> # Undefined in live ebuilds.
>> [[ ${PV} !=  ]] && : ${MATE_TARBALL_SUFFIX:="xz"}
> 
> You should ask upstream to supply .tar.lz instead, so they don't harm their 
> users.
> 
I can ask, but I don't think I understand what you mean by "harm their
users."
>>
>> # @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PN
>> # @DESCRIPTION:
>> # Name of the package as hosted on mate-desktop.org.
>> # Leave unset if package name matches PN.
>> : ${MATE_DESKTOP_ORG_PN:=$PN}
>>
>> # @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PV
>> # @DESCRIPTION:
>> # Package version string as listed on mate-desktop.org.
>> # Leave unset if package version string matches PV.
>> : ${MATE_DESKTOP_ORG_PV:=$PV}
>>
>> # @ECLASS-VARIABLE: MATE_BRANCH
>> # @DESCRIPTION:
>> # Major and minor numbers of the version number, unless live.
>> # If live ebuild, will be set to ''.
>> if [[ ${PV} ==  ]]; then
>>  : ${MATE_BRANCH:=}
>> else
>>  : ${MATE_BRANCH:=$(get_version_component_range 1-2)}
>> fi
> 
> Unless I'm missing something, the 1-2 range will return  in live version 
> as well. Unless you are trying to avoid the inherit in the live ebuild -- 
> then I don't think it's worth the extra code.
> 
I will double check and reply again if it is different, but I believe
the concern had been that if there was a major change in a , and I
temporarily revbumped the  to -r1, the 1-2 range would return
-r1 rather then the expected .
>>
>> # Set SRC_URI or EGIT_REPO_URI based on whether live
>> if [[ ${PV} ==  ]]; then
>>  EGIT_REPO_URI="
>>  https://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
>>  git://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
>>  http://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
> 
> Does github actually support http?
> 
git clone works, though, I'm unsure if it is redirecting to https.  I'll
have to double check on this.
>>  "
>>  SRC_URI=""
>> else
>>  
>> SRC_URI="http://pub.mate-desktop.org/releases/${MATE_BRANCH}/${MATE_DESKTOP_ORG_PN}-${MATE_DESKTOP_ORG_PV}.tar.${MATE_TARBALL_SUFFIX};
>> fi
>>
>> # Set HOMEPAGE for all ebuilds
>> HOMEPAGE="http://mate-desktop.org;
>>
>> # Set default SLOT for all ebuilds
>> SLOT="0"
> 
> Don't do that. Ebuilds without explicit SLOT are less readable.
> 
Sure.
>>
>>
>>

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-10 Thread Michał Górny 
On Thu, 9 Jun 2016 08:19:43 -0400
NP-Hardass  wrote:

> # Ensure availibility of xz-utils on old EAPIs
> if [[ "${EAPI:-0}" -lt "6" ]]; then
>   DEPEND="app-arch/xz-utils"
> fi

One more thing. What is the rationale for this? I've tried hard, and I
can't find anything EAPI-conditional about dependency on xz-utils.

-- 
Best regards,
Michał Górny



pgpTW9T6NONBg.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-10 Thread Michał Górny 
Dnia 9 czerwca 2016 14:19:43 CEST, NP-Hardass  
napisał(a):
>Greetings all,
>
>Sorry for the delay, had lots of recurrent hardware issues the last
>month or so.
>I will be adding this to the MATE project repo after I get your
>feedback, and then into Gentoo repo after I've had some users test out
>the new packages/eclass.
>
>Just a reminder/summary:
>There are 40-50 ebuilds in the MATE desktop environment, with a fair
>bit
>of overlap in the ebuild code, so I thought it best to create an eclass
>to handle that.  MATE is a fork of GNOME 2 so I used the gnome.org
>eclass as a reference for the mate-desktop.org eclass.  Additionally,
>there is much in MATE that is still very much in line with the gnome2
>eclass.  Rather than having to edit 40-50 ebuilds if we become
>divergent, I thought it more purdent to just create a separete mate_*
>namespace. For functions that are currently equivalent, my phase
>functions are stubs to the gnome2 phase functions.
>
>
>Thanks for taking the time to look these over and give your feedback.
>(Also, apologies for the thrown together email, I was having trouble
>getting git-send working to the mailing list)
>
>--
>NP-Hardass
>
>###
>mate-desktop.org.eclass
>###
>
>
># Copyright 1999-2016 Gentoo Foundation
># Distributed under the terms of the GNU General Public License v2
># $Id$
>
># @ECLASS: mate-desktop.org.eclass
># @MAINTAINER:
># m...@gentoo.org
># @AUTHOR:
># Authors: NP-Hardass  based upon the gnome.org
>eclass.
># @BLURB: Helper eclass for mate-desktop.org hosted archives
># @DESCRIPTION:
># Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well
>as
># exporting some useful values like the MATE_BRANCH
>
># Old EAPIs are banned.
>case "${EAPI:-0}" in
>   5|6) ;;
>   *) die "EAPI=${EAPI} is not supported" ;;
>esac
>
>if [[ ${PV} ==  ]]; then
>   inherit git-r3
>else
>   inherit versionator
>fi
>
># Ensure availibility of xz-utils on old EAPIs
>if [[ "${EAPI:-0}" -lt "6" ]]; then

EAPI is not a number and must not be treated like a number.

>   DEPEND="app-arch/xz-utils"
>fi
>
># @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX
># @INTERNAL
># @DESCRIPTION:
># All projects hosted on mate-desktop.org provide tarballs as tar.xz.
># Undefined in live ebuilds.
>[[ ${PV} !=  ]] && : ${MATE_TARBALL_SUFFIX:="xz"}

You should ask upstream to supply .tar.lz instead, so they don't harm their 
users.

>
># @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PN
># @DESCRIPTION:
># Name of the package as hosted on mate-desktop.org.
># Leave unset if package name matches PN.
>: ${MATE_DESKTOP_ORG_PN:=$PN}
>
># @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PV
># @DESCRIPTION:
># Package version string as listed on mate-desktop.org.
># Leave unset if package version string matches PV.
>: ${MATE_DESKTOP_ORG_PV:=$PV}
>
># @ECLASS-VARIABLE: MATE_BRANCH
># @DESCRIPTION:
># Major and minor numbers of the version number, unless live.
># If live ebuild, will be set to ''.
>if [[ ${PV} ==  ]]; then
>   : ${MATE_BRANCH:=}
>else
>   : ${MATE_BRANCH:=$(get_version_component_range 1-2)}
>fi

Unless I'm missing something, the 1-2 range will return  in live version as 
well. Unless you are trying to avoid the inherit in the live ebuild -- then I 
don't think it's worth the extra code.

>
># Set SRC_URI or EGIT_REPO_URI based on whether live
>if [[ ${PV} ==  ]]; then
>   EGIT_REPO_URI="
>   https://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
>   git://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
>   http://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git

Does github actually support http?

>   "
>   SRC_URI=""
>else
>   
> SRC_URI="http://pub.mate-desktop.org/releases/${MATE_BRANCH}/${MATE_DESKTOP_ORG_PN}-${MATE_DESKTOP_ORG_PV}.tar.${MATE_TARBALL_SUFFIX};
>fi
>
># Set HOMEPAGE for all ebuilds
>HOMEPAGE="http://mate-desktop.org;
>
># Set default SLOT for all ebuilds
>SLOT="0"

Don't do that. Ebuilds without explicit SLOT are less readable.

>
>
>###
>mate.eclass
>###
>
>
># Copyright 1999-2016 Gentoo Foundation
># Distributed under the terms of the GNU General Public License v2
># $Id$
>
># @ECLASS: mate.eclass
># @MAINTAINER:
># m...@gentoo.org
># @AUTHOR:
># Authors: NP-Hardass  based upon the gnome2
># and autotools-utils eclasses
># @BLURB: Provides phases for MATE based packages.
># @DESCRIPTION:
># Exports portage base functions used by ebuilds written for packages
>using the
># MATE framework. Occassionally acts as a wrapper to gnome2 due to the
># fact that MATE is a GNOME fork. For additional functions, see
>gnome2-utils.eclass.

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-09 Thread Jason Zaman 
On Thu, Jun 09, 2016 at 08:19:43AM -0400, NP-Hardass wrote:
> # Old EAPIs are banned.
> case "${EAPI:-0}" in
>   5|6) ;;
>   *) die "EAPI=${EAPI} is not supported" ;;
> esac

How reasonable would it be to ban EAPI5 as well? This is a new eclass so
it may be better to just take the time to go to EAPI6 directly and not
have to migrate 5->6 later on.


> # @FUNCTION: python_cond_func_wrap
> # @DESCRIPTION: Wraps a function for conditional python use, to run for each
> # python implementation in the build directory.
> python_cond_func_wrap() {
>   if use python; then
>   python_foreach_impl run_in_build_dir "$@"
>   else
>   $@
>   fi
> }

I dont see where you inherited the python eclasses? You also probably
need to use use_if_iuse (from eutils.eclass) instead since it seems like
python might not be in all the ebuilds. Afaik, you're not allowed to
call use foo if foo is not in IUSE already.

Also I'm not sure if having functions start with python_ could lead to
conflicts later on with the python eclasses?

Other than these minor things, look good!
-- Jason

Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-09 Thread NP-Hardass 
Greetings all,

Sorry for the delay, had lots of recurrent hardware issues the last
month or so.
I will be adding this to the MATE project repo after I get your
feedback, and then into Gentoo repo after I've had some users test out
the new packages/eclass.

Just a reminder/summary:
There are 40-50 ebuilds in the MATE desktop environment, with a fair bit
of overlap in the ebuild code, so I thought it best to create an eclass
to handle that.  MATE is a fork of GNOME 2 so I used the gnome.org
eclass as a reference for the mate-desktop.org eclass.  Additionally,
there is much in MATE that is still very much in line with the gnome2
eclass.  Rather than having to edit 40-50 ebuilds if we become
divergent, I thought it more purdent to just create a separete mate_*
namespace. For functions that are currently equivalent, my phase
functions are stubs to the gnome2 phase functions.


Thanks for taking the time to look these over and give your feedback.
(Also, apologies for the thrown together email, I was having trouble
getting git-send working to the mailing list)

--
NP-Hardass

###
mate-desktop.org.eclass
###


# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: mate-desktop.org.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass  based upon the gnome.org
eclass.
# @BLURB: Helper eclass for mate-desktop.org hosted archives
# @DESCRIPTION:
# Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well as
# exporting some useful values like the MATE_BRANCH

# Old EAPIs are banned.
case "${EAPI:-0}" in
5|6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

if [[ ${PV} ==  ]]; then
inherit git-r3
else
inherit versionator
fi

# Ensure availibility of xz-utils on old EAPIs
if [[ "${EAPI:-0}" -lt "6" ]]; then
DEPEND="app-arch/xz-utils"
fi

# @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX
# @INTERNAL
# @DESCRIPTION:
# All projects hosted on mate-desktop.org provide tarballs as tar.xz.
# Undefined in live ebuilds.
[[ ${PV} !=  ]] && : ${MATE_TARBALL_SUFFIX:="xz"}

# @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PN
# @DESCRIPTION:
# Name of the package as hosted on mate-desktop.org.
# Leave unset if package name matches PN.
: ${MATE_DESKTOP_ORG_PN:=$PN}

# @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PV
# @DESCRIPTION:
# Package version string as listed on mate-desktop.org.
# Leave unset if package version string matches PV.
: ${MATE_DESKTOP_ORG_PV:=$PV}

# @ECLASS-VARIABLE: MATE_BRANCH
# @DESCRIPTION:
# Major and minor numbers of the version number, unless live.
# If live ebuild, will be set to ''.
if [[ ${PV} ==  ]]; then
: ${MATE_BRANCH:=}
else
: ${MATE_BRANCH:=$(get_version_component_range 1-2)}
fi

# Set SRC_URI or EGIT_REPO_URI based on whether live
if [[ ${PV} ==  ]]; then
EGIT_REPO_URI="
https://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
git://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
http://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
"
SRC_URI=""
else

SRC_URI="http://pub.mate-desktop.org/releases/${MATE_BRANCH}/${MATE_DESKTOP_ORG_PN}-${MATE_DESKTOP_ORG_PV}.tar.${MATE_TARBALL_SUFFIX};
fi

# Set HOMEPAGE for all ebuilds
HOMEPAGE="http://mate-desktop.org;

# Set default SLOT for all ebuilds
SLOT="0"


###
mate.eclass
###


# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: mate.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass  based upon the gnome2
# and autotools-utils eclasses
# @BLURB: Provides phases for MATE based packages.
# @DESCRIPTION:
# Exports portage base functions used by ebuilds written for packages
using the
# MATE framework. Occassionally acts as a wrapper to gnome2 due to the
# fact that MATE is a GNOME fork. For additional functions, see
gnome2-utils.eclass.

# Check EAPI only
case "${EAPI:-0}" in
5|6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# 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:-""}

inherit gnome2 autotools mate-desktop.org

case "${EAPI:-0}" in
5|6)
EXPORT_FUNCTIONS src_prepare src_configure src_install 
pkg_preinst
pkg_postinst

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-14 Thread Alexis Ballier 
On Wed, 13 Apr 2016 12:21:40 -0400
NP-Hardass  wrote:

> >> 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?


not on top of my head, but some eclasses do that already (python-r1 for
python-utils-r1 for example), and it seems natural that eclass author
defines its API :)

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-13 Thread NP-Hardass 
-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

2016-04-13 Thread Alexis Ballier 
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] [RFC] New eclass: mate

2016-04-13 Thread NP-Hardass 
-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

2016-04-13 Thread Alexis Ballier 
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)?

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-12 Thread NP-Hardass 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/2016 02:42 PM, Pacho Ramos wrote:
> Hi!
> 
> El lun, 11-04-2016 a las 22:04 -0400, NP-Hardass escribió:
>> [...] # @FUNCTION: ematedocize # @DESCRIPTION: A wrapper around
>> mate-doc-common ematedocize() { ebegin "Running mate-doc-common
>> --copy" mate-doc-common --copy || die eend $? }
>> 
> 
> Have you think in reporting this to autotools.eclass maintainers to
> add the needed logic to autotools.eclass as done for all the other
> stuff like gnome-doc, intltool...

I hadn't, though, that would make things much easier  I'll reach out
to them and inquire.  Thanks for the suggestion.

> 
>> # @FUNCTION: mate_src_prepare # @DESCRIPTION: # Call
>> gnome2_src_prepare to handle environment setup and patching, 
>> then # call eautoreconf if necessary mate_src_prepare() { 
>> debug-print-function ${FUNCNAME} "$@"
>> 
>> local force_autoreconf=${FORCE_AUTORECONF:-false} [[ ${PV} ==
>>  ]] && force_autoreconf=true
>> 
>> gen_chksum() { find '(' -name 'Makefile.am' \ -o -name
>> 'configure.ac' \ -o -name 'configure.in' ')' \ -exec cksum + |
>> sort -k2 }
>> 
>> local chksum=$(gen_chksum)
>> 
>> gnome2_src_prepare
>> 
>> if ${force_autoreconf} || [[ ${chksum} != $(gen_chksum) ]]; then 
>> eautoreconf ematedocize fi }
>> 
> 
> I wonder if maybe this handling of "automatic eautoreconf" should
> be moved to a more general eclass as there are some consumers that
> are reimplementing this different times :/
> 
> In the past we could rely on autotools-utils.eclass for this, but
> now, it looks like it needs to be redone in several other eclasses
> (for example, xorg one)
> 
> But it's only a question/opinion, I am not blocking your change or 
> similar ;)
> 

I don't have my heart set in keeping it MATE specific.  I just assumed
that since the old eclass autotools-utils was banned without
deprecation and had no successor that I was on my own.  Moreover,
since EAPI 6 forces eapply_user, we have no idea whether a user is
going to choose to patch the autotools build system, requiring an
eautoreconf, so, unfortunately, I think automatic detection of when to
eautoreconf is a necessity.

Does anyone else agree that this is a necessity for autotools based
ebuilds in EAPI 6, and if so, any suggestions on were to put it so
that it can be reused as much as possible?

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDVJiAAoJEBzZQR2yrxj7+XcQAIW54FgL3DMRxnjvOdaUJfT6
HSY0zFIX+Z9LXPRgpg8HS74pqs9E4KV8hjbAjlIF1Na3QBjfisViQzbyB6AIYhqg
JjfJxgcCK/j0kDWx9AXZJIuBhmoKZMzklde0cqDpcAk2ugdq+AxUu+zvhn7tgbTP
8CF1N1137NIvW0zSUuEima87r8oFWkgWXyGEy93O9++KM1t9QTStOdSb84tqfuhN
iYgYe2qWVGfhYQ1InIQ9OJyazf+b112+WWuUfp9IpmhT5WeoFkXk8hfNE8dYl0G2
FnwiEYpAOMhiOeWrI0QkZ8lnwyunxmlfvmxTygtjK4a8c8HPC3sGmzwJ6Bo74kwk
uLPVsh4ZcWmVnadgKJ/uI/NLc0BREqZQbOYaLDhgHYvoizzeXeisb0H8P6VmtOIN
xI4HOFrfAn5biiBaQiVjilGJCByhMXpnJuINO+dA/ruCGyX/AEmhl+DrSxo27WmO
1q4kO6vie8mqHvk8vvolnQLaULh9xMBsntCf6tzsTpv3Fnb4paeYr+aVOJVNbFxL
hwzkQoV2OJg05uFRkRaq/q6rupbSNoia5+J54GOcwO0+nYxRpQCK/g+7wRdfRlFo
9jmDztDOSqoPOzwnUnHUwPwFDWcCCG5vJYh3wqyW22UZSeEwPfIRxxwKNYf03nn/
SoGl+TI8E8PJHEP/BlYz
=L6YE
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-12 Thread NP-Hardass 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/2016 02:44 PM, Pacho Ramos wrote:
> El lun, 11-04-2016 a las 20:14 -0400, NP-Hardass escribió:
>> [...] # @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX # @INTERNAL #
>> @DESCRIPTION: # All projects hosted on mate-desktop.org provide
>> tarballs as tar.xz. # Undefined in live ebuilds. [[ ${PV} != 
>> ]] && : ${MATE_TARBALL_SUFFIX:="xz"}
>> 
> 
> If you are going to support eapi <6 you will probably need to do: 
> DEPEND="${DEPEND} app-arch/xz-utils"
> 
> as in gnome.org.eclass to ensure the needed dep is pulled in :)
> 

We briefly discussed this in #gentoo-dev yesterday.  I'm not positive
about when that statement is required and when it is not.  The PMS has
a statement that the ebuild should ensure that that xz-utils and tar
are available (as it stipulates with each and every other
archive/compression format, including tar.gz and tar.bz2).  Also
mentioned in the discussion was that because xz-utils is and has been
in @system for quite some time, for the purposes of unpack, there is
no need to DEPEND on it.
I'm quite curious where you got the EAPI 6 boundary for explicitly
depending on xz-utils from though.   Perhaps we overlooked something
when investigating it the other day.

Thanks for the feedback!

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDVARAAoJEBzZQR2yrxj7iooP/1IAVFkKr1bOtujy6g3steVm
tOWPfI9eEiDIcWOf4lBb4p/nv5AvjMTatilT6QiFnEOLhq/ZaWsOHMKE4qmQHz0U
+u762ejODK2ouR8foPmKtD04ZBkVtYmJ5N6OqWuuQ86LxLhzBsoctLPkPFZu6N//
8UWVsKo5IjNF3oTu3YfQge2Fclp4EDmN2uN9PF3PgmCvPRTrc6/5PhYkPiFYQsyf
313Cy9I2XY+ZhHHKaGawPye1QzY22L9Uvd2d3WatePvtRtS+O3rJXEL8rqk8f4sB
LSud/G+Z5fW1159rGKpUnXDwrBY1A0/j6VS5pe/Fwl4z9qKPmcEo9HcJsxvsMixW
PXZaqfAuYZYaAxcvoJbBPvNn2z+pTLoHJksCasH0ROn3wkDLAWYpokPoCJsa3NcF
JC7k9rRdTjQiRfbUppcDushZ2oGRGxOb1a4oKnNxldaazUhP6ukDR1oqmfmnd1+p
PUt07yR6AhonjmNByO8MPGaNeSDdSSJhYvwCkTRbTcN6jYDkKJOMDcEZIKQmqect
J+bVg7wI7FmI0uUzg7QIIeGrvAemMxEEWHMqxtiKfA6PcZjGJB2x7AFLZkOVho7U
nm758/BgCpryanha36IVzapTN+26lZ9ZTmxyn7kghHoWMThv6m1KuLYsl7GTo/hl
qTVllQPg+iAYvrXadWp6
=+uhR
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-12 Thread Pacho Ramos 
El lun, 11-04-2016 a las 20:14 -0400, NP-Hardass escribió:
> [...]
> # @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX
> # @INTERNAL
> # @DESCRIPTION:
> # All projects hosted on mate-desktop.org provide tarballs as tar.xz.
> # Undefined in live ebuilds.
> [[ ${PV} !=  ]] && : ${MATE_TARBALL_SUFFIX:="xz"}
> 

If you are going to support eapi <6 you will probably need to do:
DEPEND="${DEPEND} app-arch/xz-utils"

as in gnome.org.eclass to ensure the needed dep is pulled in :)


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-12 Thread Pacho Ramos 
Hi!

El lun, 11-04-2016 a las 22:04 -0400, NP-Hardass escribió:
> [...]
> # @FUNCTION: ematedocize
> # @DESCRIPTION: A wrapper around mate-doc-common
> ematedocize() {
> ebegin "Running mate-doc-common --copy"
> mate-doc-common --copy || die
> eend $?
> }
> 

Have you think in reporting this to autotools.eclass maintainers to add
the needed logic to autotools.eclass as done for all the other stuff
like gnome-doc, intltool...

> # @FUNCTION: mate_src_prepare
> # @DESCRIPTION:
> # Call gnome2_src_prepare to handle environment setup and patching,
> then
> # call eautoreconf if necessary
> mate_src_prepare() {
> debug-print-function ${FUNCNAME} "$@"
> 
> local force_autoreconf=${FORCE_AUTORECONF:-false}
> [[ ${PV} ==  ]] && force_autoreconf=true
> 
> gen_chksum() {
> find '(' -name 'Makefile.am' \
> -o -name 'configure.ac' \
> -o -name 'configure.in' ')' \
> -exec cksum + | sort -k2
> }
> 
> local chksum=$(gen_chksum)
> 
> gnome2_src_prepare
> 
> if ${force_autoreconf} || [[ ${chksum} != $(gen_chksum) ]];
> then
> eautoreconf
> ematedocize
> fi
> }
> 

I wonder if maybe this handling of "automatic eautoreconf" should be
moved to a more general eclass as there are some consumers that are
reimplementing this different times :/ 

In the past we could rely on autotools-utils.eclass for this, but now,
it looks like it needs to be redone in several other eclasses (for
example, xorg one)

But it's only a question/opinion, I am not blocking your change or
similar ;)



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-11 Thread NP-Hardass 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/11/2016 08:14 PM, NP-Hardass wrote:
> On 04/11/2016 01:09 AM, NP-Hardass wrote:
>> Greetings all,
> 
>> As all potential new eclasses are supposed to be discussed here,
>> I thought I'd file a message and see if anyone had anything to 
>> contribute on the matter.
> 
>> I'm in the midst of a major version bump for the entirety of the 
>> MATE desktop environment, consisting of 40-50 packages.  There is
>> a huge amount of repetition in my ebuilds, and a lot of things
>> are formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits,
>> src_prepare, etc).  As such, I think that moving all of that to
>> an eclass would greatly simplify my life and my ebuilds, so I
>> thought I'd look into creating an eclass.
> 
>> Any opinions either way?   Thanks in advance.
> 
> 
> 
> 
> A little background, MATE is a fork of GNOME, so there are many
> things in common, however, the two aren't always in sync.  As such,
> there is often code reuse, but not always.  For example, GNOME has
> deprecated GNOME_DEBUG macros whereas MATE has not done so yet.
> 
> Attached are two eclasses mate-desktop.org.eclass and mate.eclass.
> 
> mate-desktop.org.eclass mimics the gnome.org eclass.  It defines a 
> couple of useful variables, as well as sets SRC_URI or
> EGIT_REPO_URI for a live ebuild.
> 
> mate.eclass is supposed to parallel gnome2.eclass.  A couple of
> notes: mate-desktop.org.eclass is necessary to override all of the
> defaults in gnome.org.eclass which are not applicable to MATE. The
> src_prepare function is borrowed from autotools-utils.  With EAPI
> 6, if any user is capable of modifying the build system via
> eapply_user, I'd like to be able to detect and regenerate the build
> system accordingly. Additionally, upstream does not supply
> Makefiles or configure scripts for live ebuilds, so I always have
> to run eautoreconf in those cases. Stubs: Well, you will probably
> notice that I have stubs to the gnome2 remaining functions.  This
> was done for several reasons.  1) in the event that the gnome2
> eclass goes in a different direction than MATE, it's easy to switch
> our own implementation, and 2) if I don't and I have reference to
> the gnome2 eclass, I have to explicitly inherit it in all ebuilds,
> which somewhat defeats the point the indirection gained by having
> the mate eclass.   I'd have to inherit gnome2 mate mate-desktop.org
> in every ebuild to ensure that everything is inherited properly.
> It's a little bit messy, but still doable.  But for the previous
> reason, built in independence from the gnome eclass if needed, it
> seems much easier to me to stub out gnome2 in the meantime .
> 
> 
Added new function to wrap around a MATE autotools function
mate-doc-common and add it to src_prepare

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDFeaAAoJEBzZQR2yrxj7LIgP+QGFJ+xdigWpxSDIIqabwozT
qL6hwvAQVHe3gBjGvs3FPOo+FJgzteQE4pRhhkU+g+Zgs9z1f7NIQQZbMwfVrHg+
KYKdufL4Wd2rF/X1qAf5EOqToBxZxpEYH0rPlfirOE4WA0HC5Gke0fwppeu6L8S3
7+N68ZdPKYnJ55+FZAiQCuy9QX3gDHsKhSpd1P4q5+Fi6D+qGYFalOlhhtW6qiOR
Rv41/xEabUha4V9H7YG5j+rROL5mSFchIT6wzx5dDTwQKS2dTclcqEbuS/k45E44
aemZFfb6l8Ymg+o28sCidPlOYyVaF5j7VbIAHNwEN4DNlbbpOJKAE5wTc6zrAyv5
zRVmmlxMlJvwr26faQsKgEGcVTWenmyCDeguSwgDetv1oQrzHtkI9lJMoUdRW39S
5nNp3mA2isUVmQIZRidAnPIJwLWBo7pmRZ67leCuK1UXGvGQWFDKXzPcRShTZRYb
nnE5VamFBlZtfpAnuoLYhNf9i21GJ/SJMxEwWNutdhf343qogfOk+Q7cKuYATEwm
OP499WmH7WNNjMnQiiyj9fC3epXslHN9ibYNoq1tf1Q3s5wIvzJ0ivcD9HZxxERv
usYALHiK1YZrjGpy3Tm1+pt44jwCRt+hVBL+2fpez3ZOpPqRjW24KCnM1ZHILbx4
CSPRFgrQnPUMI4/r6Ew9
=JV4I
-END PGP SIGNATURE-
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: mate.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass  based upon the gnome2
# and autotools-utils eclasses
# @BLURB: Provides phases for MATE based packages.
# @DESCRIPTION:
# Exports portage base functions used by ebuilds written for packages using the
# MATE framework. Occassionally acts as a wrapper to gnome2 due to the
# fact that MATE is a GNOME fork. For additional functions, see 
gnome2-utils.eclass.

# Check EAPI only
case "${EAPI:-0}" in
5|6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# 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:-""}

inherit autotools gnome2 mate-desktop.org

case "${EAPI:-0}" in
5|6)
EXPORT_FUNCTIONS src_prepare src_configure src_install 
pkg_preinst pkg_postinst pkg_postrm
;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# Autotools requires our MATE m4 files

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-11 Thread NP-Hardass 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/11/2016 01:09 AM, NP-Hardass wrote:
> Greetings all,
> 
> As all potential new eclasses are supposed to be discussed here, I 
> thought I'd file a message and see if anyone had anything to 
> contribute on the matter.
> 
> I'm in the midst of a major version bump for the entirety of the
> MATE desktop environment, consisting of 40-50 packages.  There is a
> huge amount of repetition in my ebuilds, and a lot of things are
> formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare,
> etc).  As such, I think that moving all of that to an eclass would
> greatly simplify my life and my ebuilds, so I thought I'd look into
> creating an eclass.
> 
> Any opinions either way?   Thanks in advance.
> 
> 
> 

A little background, MATE is a fork of GNOME, so there are many things
in common, however, the two aren't always in sync.  As such, there is
often code reuse, but not always.  For example, GNOME has deprecated
GNOME_DEBUG macros whereas MATE has not done so yet.

Attached are two eclasses mate-desktop.org.eclass and mate.eclass.

mate-desktop.org.eclass mimics the gnome.org eclass.  It defines a
couple of useful variables, as well as sets SRC_URI or EGIT_REPO_URI
for a live ebuild.

mate.eclass is supposed to parallel gnome2.eclass.  A couple of notes:
mate-desktop.org.eclass is necessary to override all of the defaults
in gnome.org.eclass which are not applicable to MATE. The src_prepare
function is borrowed from autotools-utils.  With EAPI 6, if any user
is capable of modifying the build system via eapply_user, I'd like to
be able to detect and regenerate the build system accordingly.
Additionally, upstream does not supply Makefiles or configure scripts
for live ebuilds, so I always have to run eautoreconf in those cases.
Stubs: Well, you will probably notice that I have stubs to the gnome2
remaining functions.  This was done for several reasons.  1) in the
event that the gnome2 eclass goes in a different direction than MATE,
it's easy to switch our own implementation, and 2) if I don't and I
have reference to the gnome2 eclass, I have to explicitly inherit it
in all ebuilds, which somewhat defeats the point the indirection
gained by having the mate eclass.   I'd have to inherit gnome2 mate
mate-desktop.org in every ebuild to ensure that everything is
inherited properly.  It's a little bit messy, but still doable.  But
for the previous reason, built in independence from the gnome eclass
if needed, it seems much easier to me to stub out gnome2 in the meantime
.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDD34AAoJEBzZQR2yrxj7ELkQAJK78s2tNt67XR7fgIYWZkTa
a52MsFdW5e14yqKZAmKZqIde3zRo65BAoa15BVscM2o9iH1CtJolbrq0i603OBej
RGt5RkgOqmUYg8lU/z1fyX7PLzm3ukTBSNQ0Y5m5jofo2sbg4WMFiaaQkmvChnQd
TA5dI+nMzz8gfQJvXoorj+JZziOikH4i8lsge2QKP7IUDe16fjUO8VM8J+5v4uk+
XXeIPFq3PXoHeGW9jLo9jibapntDlPOStoalY5dRIkIZSpe124TfVhCSOMeuWtRB
VzvvaW+D2MFL9NU2WcsQtU8H71CY/bZl3qPiA9n6OcFowIyVXBP9W7lhpcBmWbYx
HIsI8UEXriuMJPhiZ/mzkEKaXohElcvbolvQigejGCxzJVQ1fxpoHINXaN/KCEQ8
fxsKeLCM/toPuFcqjru1znZb05cLm1UAcN15YK3ldrcJNGY9tPxHj09dt74eIWor
49HZeFSftef637vFA+3NEN9aVVRyd9O9Fc+wK8FI7ki3O2br4SoOw122NUfjFWoB
4xguWOJjspcbxobzK7nzrKhTYLDhh+oymTj4TLmmzvTo3zgBgYhbVJNP5HoycfPB
nZBzYZIht0bl/BbdGvdOyDVacLG+X7QlWKcx/bUmcrv3rih59D8XrtzlVhOavvhW
RZ4Wo+feNwXrLN9aOfcL
=GGgO
-END PGP SIGNATURE-
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: mate.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass  based upon the gnome2
# and autotools-utils eclasses
# @BLURB: Provides phases for MATE based packages.
# @DESCRIPTION:
# Exports portage base functions used by ebuilds written for packages using the
# MATE framework. Occassionally acts as a wrapper to gnome2 due to the
# fact that MATE is a GNOME fork. For additional functions, see 
gnome2-utils.eclass.

# Check EAPI only
case "${EAPI:-0}" in
5|6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# 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:-""}

inherit autotools gnome2 mate-desktop.org

case "${EAPI:-0}" in
5|6)
EXPORT_FUNCTIONS src_prepare src_configure src_install 
pkg_preinst pkg_postinst pkg_postrm
;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# Autotools requires our MATE m4 files
DEPEND=">=mate-base/mate-common-${MATE_BRANCH}"


# Wrapper function for handling phases when python is available as bindings only
# @FUNCTION: python_cond_func_wrap
# @DESCRIPTION: Wraps a function for conditional python use, to

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-11 Thread Daniel Campbell 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/10/2016 10:09 PM, NP-Hardass wrote:
> Greetings all,
> 
> As all potential new eclasses are supposed to be discussed here, I 
> thought I'd file a message and see if anyone had anything to 
> contribute on the matter.
> 
> I'm in the midst of a major version bump for the entirety of the
> MATE desktop environment, consisting of 40-50 packages.  There is a
> huge amount of repetition in my ebuilds, and a lot of things are
> formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare,
> etc).  As such, I think that moving all of that to an eclass would
> greatly simplify my life and my ebuilds, so I thought I'd look into
> creating an eclass.
> 
> Any opinions either way?   Thanks in advance.
> 
> 
> 
Sounds like a prime use case for an eclass. If I were in your position
I'd be sure to get reviews from more experienced eclass writers along
the way to make sure you're not setting yourself up for bad API design.
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXC07lAAoJEAEkDpRQOeFwqA4P/0GRudtO39UawnAQRW+N3/Un
JyyFN5Oej9bIJpMYyE7tz77N1SdUjla6yW/2WaL/HtzTeeETjp/ThlOXvweYE367
mCz7OJ/q9Fo20TGfPaBI0xIvlcmv+BDdTpjJc1czRlC+1j+mLa9RDG+byMiwnQIa
QVK3sUYAvypQqGIOZSlM4nCRwVT1CSBnSDlaJqlUIUJNciY9iqXyKwzCX0xUJCpo
pQHH2S05Bhx8c0rpK0x/MkqfhTAaLBPQDd/7Szozuy/MTb3Zx3aIV4bE0Z5D5uYq
B5ReTw0D0/cZqi9dA5HeEqMwEJJm6DRvs/km9bX07LDsIm0otvMCho3LzUY76SyS
4wtbNrHVBdQmM1XF9RdJ8Nd6HA3oozBwgs7tNRj0mLNG0irpc4q3CdC0ZYjklYVZ
KzTS2f7j1nnBvMynVYehlhNLUzpKwnUNIo1SFLrc5W/3ZQb9RtuwUYerP6sSoL8E
och22zjtD8PesT5exTXf5M3DRB5xO6kDcdCdzASdEpdjcLrCt3aDZTejhFrIAiJq
0LpdiZMyeC/z8bLKVGpMuBcZkD+eI9YzzdGC4FDU8AnEV17lGZfptqbUcGYL82wC
9FdlXieeTUuFWwIq0uM1gm4Sr1RMZ0/+Y/dqQBAKM+gFbZ8V+th5c8nKbdDt+I4o
4WOoBEg3fMnwPxga7DGT
=ks2J
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] New eclass: mate

2016-04-10 Thread M. J. Everitt 
On 11/04/16 06:09, NP-Hardass wrote:
> Greetings all,
>
> As all potential new eclasses are supposed to be discussed here, I
> thought I'd file a message and see if anyone had anything to
> contribute on the matter.
>
> I'm in the midst of a major version bump for the entirety of the MATE
> desktop environment, consisting of 40-50 packages.  There is a huge
> amount of repetition in my ebuilds, and a lot of things are formulaic
> (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare, etc).  As
> such, I think that moving all of that to an eclass would greatly
> simplify my life and my ebuilds, so I thought I'd look into creating
> an eclass.
>
> Any opinions either way?   Thanks in advance.
>
>
I say go for it .. post up any milestones for review, of course... :]



signature.asc
Description: OpenPGP digital signature