[gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Samuli Suominen]

On 29-05-2012 11:32:10 +0300, Samuli Suominen wrote:
 > On 05/29/2012 10:09 AM, Fabian Groffen wrote:
 >> > Please do not hestitate
 >> > to repeat your agenda item here with a pointer if you previously
 >> > suggested one (since the last meeting).
 >> >
 >> > The agenda for the next meeting will be sent out in a week by the
 >> > meeting's chairman.
 >> >
 >> > Please respond to gentoo-project list, if possible.
 >> >
 >> >
 >>
 >> This one,
 >>
 >> 
http://archives.gentoo.org/gentoo-dev/msg_920c6d6daafe7702bfa3b8a2bc21e0c1.xml

 > Can you indicate what the council has to vote on/decide for this one?

EAPI=5

optional: "$@" placement in default for src_configure()

econf "$@"

optional: "$@" placement in default for src_compile()

emake "$@"

this one is what I'm really after for:

default for src_install() in EAPI=5 should accept "$@" in correct place 
to avoid usage of EXTRA_EMAKE within ebuilds/eclasses and to avoid 
duplicating the Portage code for DOCS.
NOTE: When this was last voted on for EAPI=3, we didn't have this DOCS 
handling, and this wasn't important yet.

emake DESTDIR="${D}" "$@" install

 > In anticipation on the answer, you probably need to formalise what you
 > want, so the PMS guys can be a bit more happy on what you really mean
 > for all corner cases now, and in the future.  That in turn allows
 > council members to bless the feature for a future EAPI (or not).

I'm not good with documentation so this sounds too much of a curve, 
sorry... Unfortunate if this boils down to it.

Thanks,
Fabian

[gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Ulrich Mueller]

>>>>> On Sun, 03 Jun 2012, Samuli Suominen wrote:

>> On 05/29/2012 10:09 AM, Fabian Groffen wrote:
> http://archives.gentoo.org/gentoo-dev/msg_920c6d6daafe7702bfa3b8a2bc21e0c1.xml

>> Can you indicate what the council has to vote on/decide for this one?

> EAPI=5

> optional: "$@" placement in default for src_configure()

> econf "$@"

> optional: "$@" placement in default for src_compile()

> emake "$@"

I still don't see the point of it. econf or emake could just be called
directly. We won't gain anything by allowing arguments, but only
complicate things.

> this one is what I'm really after for:

> default for src_install() in EAPI=5 should accept "$@" in correct place 
> to avoid usage of EXTRA_EMAKE within ebuilds/eclasses and to avoid 
> duplicating the Portage code for DOCS.
> NOTE: When this was last voted on for EAPI=3, we didn't have this DOCS 
> handling, and this wasn't important yet.

> emake DESTDIR="${D}" "$@" install

Again, this could be called directly, which has the advantage that it
makes it obvious that src_install isn't the default.

Ulrich

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Samuli Suominen]

On 06/03/2012 03:01 AM, Ulrich Mueller wrote:
>>>>>> On Sun, 03 Jun 2012, Samuli Suominen wrote:
>
>>> On 05/29/2012 10:09 AM, Fabian Groffen wrote:
>> http://archives.gentoo.org/gentoo-dev/msg_920c6d6daafe7702bfa3b8a2bc21e0c1.xml
>
>>> Can you indicate what the council has to vote on/decide for this one?
>
>> EAPI=5
>
>> optional: "$@" placement in default for src_configure()
>
>> econf "$@"
>
>> optional: "$@" placement in default for src_compile()
>
>> emake "$@"
>
> I still don't see the point of it. econf or emake could just be called
> directly. We won't gain anything by allowing arguments, but only
> complicate things.
>
>> this one is what I'm really after for:
>
>> default for src_install() in EAPI=5 should accept "$@" in correct place
>> to avoid usage of EXTRA_EMAKE within ebuilds/eclasses and to avoid
>> duplicating the Portage code for DOCS.
>> NOTE: When this was last voted on for EAPI=3, we didn't have this DOCS
>> handling, and this wasn't important yet.
>
>> emake DESTDIR="${D}" "$@" install
>
> Again, this could be called directly, which has the advantage that it
> makes it obvious that src_install isn't the default.

The difference is working the tree when you have to alter ebuilds which 
have been written like:

DOCS=( AUTHORS README.NOW "${FILESDIR}"/README.Gentoo )

src_install() {
	default
	
	echo "Some command here."
}

At this point you have to move content of DOCS which may or may not rely 
on the ""quoting with array"". Remove the call to default. And then 
duplicate the EAPI=4 default into the ebuild.

And then replicate that every month dozen times and keep on doing it for 
some months. Get frustrated.

If that's not enough, then you get all excited about EAPI=4 and finally 
think you have a replacement for base.eclass to port xfconf.eclass away 
from the thing when you only used it for default src_install() to avoid 
code duplication...

Think you are all done, and then get complainment that support for extra 
arguments for xfconf_src_install was killed, and was required for things 
like:

xfconf_src_install htmldirectory=/usr/share/doc/${PF}/html 
imagesdir=/usr/share/doc/${PF}/html/images

Where sedding the build system runs maintainer mode at .in level, and 
runnning autotools (.am level) requires heavy documentation dependencies.
You go back to base.eclass and get frustrated more.

I hope that clears things up ;-)

- Samuli

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Samuli Suominen]

On 06/03/2012 06:20 AM, Samuli Suominen wrote:
> On 06/03/2012 03:01 AM, Ulrich Mueller wrote:
>>>>>>> On Sun, 03 Jun 2012, Samuli Suominen wrote:
>>
>>>> On 05/29/2012 10:09 AM, Fabian Groffen wrote:
>>> http://archives.gentoo.org/gentoo-dev/msg_920c6d6daafe7702bfa3b8a2bc21e0c1.xml
>>>
>>
>>>> Can you indicate what the council has to vote on/decide for this one?
>>
>>> EAPI=5
>>
>>> optional: "$@" placement in default for src_configure()
>>
>>> econf "$@"
>>
>>> optional: "$@" placement in default for src_compile()
>>
>>> emake "$@"
>>
>> I still don't see the point of it. econf or emake could just be called
>> directly. We won't gain anything by allowing arguments, but only
>> complicate things.
>>
>>> this one is what I'm really after for:
>>
>>> default for src_install() in EAPI=5 should accept "$@" in correct place
>>> to avoid usage of EXTRA_EMAKE within ebuilds/eclasses and to avoid
>>> duplicating the Portage code for DOCS.
>>> NOTE: When this was last voted on for EAPI=3, we didn't have this DOCS
>>> handling, and this wasn't important yet.
>>
>>> emake DESTDIR="${D}" "$@" install
>>
>> Again, this could be called directly, which has the advantage that it
>> makes it obvious that src_install isn't the default.
>
> The difference is working the tree when you have to alter ebuilds which
> have been written like:
>
> DOCS=( AUTHORS README.NOW "${FILESDIR}"/README.Gentoo )
>
> src_install() {
> default
>
> echo "Some command here."
> }
>
> At this point you have to move content of DOCS which may or may not rely
> on the ""quoting with array"". Remove the call to default. And then
> duplicate the EAPI=4 default into the ebuild.
>
> And then replicate that every month dozen times and keep on doing it for
> some months. Get frustrated.
>
> If that's not enough, then you get all excited about EAPI=4 and finally
> think you have a replacement for base.eclass to port xfconf.eclass away
> from the thing when you only used it for default src_install() to avoid
> code duplication...
>
> Think you are all done, and then get complainment that support for extra
> arguments for xfconf_src_install was killed, and was required for things
> like:
>
> xfconf_src_install htmldirectory=/usr/share/doc/${PF}/html
> imagesdir=/usr/share/doc/${PF}/html/images
>
> Where sedding the build system runs maintainer mode at .in level, and
> runnning autotools (.am level) requires heavy documentation dependencies.
> You go back to base.eclass and get frustrated more.
>
> I hope that clears things up ;-)
>

Also, if not implemented, what is the replacement for EXTRA_EMAKE which 
we are allowed to use from ebuilds? Or are we allowed to use it? I think 
PMS didn't forbid it the last time I checked and it has consumers in 
tree already.

And if not implemented, would the council please vote on banning the 
usage of `default` in src_install() directly from ebuilds? The syntax 
back and forth converting MUST stop.

- Samuli

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/03/2012 04:26 AM, Samuli Suominen wrote:
> On 06/03/2012 06:20 AM, Samuli Suominen wrote:
>> On 06/03/2012 03:01 AM, Ulrich Mueller wrote:
>>>>>>>> On Sun, 03 Jun 2012, Samuli Suominen wrote:
>>> 
>>>>> On 05/29/2012 10:09 AM, Fabian Groffen wrote:
>>>> http://archives.gentoo.org/gentoo-dev/msg_920c6d6daafe7702bfa3b8a2bc21e0c1.xml
>>>>
>>>>
>>>
>>>>>
>>>> 
Can you indicate what the council has to vote on/decide for this one?
>>> 
>>>> EAPI=5
>>> 
>>>> optional: "$@" placement in default for src_configure()
>>> 
>>>> econf "$@"
>>> 
>>>> optional: "$@" placement in default for src_compile()
>>> 
>>>> emake "$@"
>>> 
>>> I still don't see the point of it. econf or emake could just be
>>> called directly. We won't gain anything by allowing arguments,
>>> but only complicate things.
>>> 
>>>> this one is what I'm really after for:
>>> 
>>>> default for src_install() in EAPI=5 should accept "$@" in
>>>> correct place to avoid usage of EXTRA_EMAKE within
>>>> ebuilds/eclasses and to avoid duplicating the Portage code
>>>> for DOCS. NOTE: When this was last voted on for EAPI=3, we
>>>> didn't have this DOCS handling, and this wasn't important
>>>> yet.
>>> 
>>>> emake DESTDIR="${D}" "$@" install
>>> 
>>> Again, this could be called directly, which has the advantage
>>> that it makes it obvious that src_install isn't the default.
>> 
>> The difference is working the tree when you have to alter ebuilds
>> which have been written like:
>> 
>> DOCS=( AUTHORS README.NOW "${FILESDIR}"/README.Gentoo )
>> 
>> src_install() { default
>> 
>> echo "Some command here." }
>> 
>> At this point you have to move content of DOCS which may or may
>> not rely on the ""quoting with array"". Remove the call to
>> default. And then duplicate the EAPI=4 default into the ebuild.
>> 
>> And then replicate that every month dozen times and keep on doing
>> it for some months. Get frustrated.
>> 
>> If that's not enough, then you get all excited about EAPI=4 and
>> finally think you have a replacement for base.eclass to port
>> xfconf.eclass away from the thing when you only used it for
>> default src_install() to avoid code duplication...
>> 
>> Think you are all done, and then get complainment that support
>> for extra arguments for xfconf_src_install was killed, and was
>> required for things like:
>> 
>> xfconf_src_install htmldirectory=/usr/share/doc/${PF}/html 
>> imagesdir=/usr/share/doc/${PF}/html/images
>> 
>> Where sedding the build system runs maintainer mode at .in level,
>> and runnning autotools (.am level) requires heavy documentation
>> dependencies. You go back to base.eclass and get frustrated
>> more.
>> 
>> I hope that clears things up ;-)
>> 
> 
> Also, if not implemented, what is the replacement for EXTRA_EMAKE
> which we are allowed to use from ebuilds? Or are we allowed to use
> it? I think PMS didn't forbid it the last time I checked and it has
> consumers in tree already.
> 
> And if not implemented, would the council please vote on banning
> the usage of `default` in src_install() directly from ebuilds? The
> syntax back and forth converting MUST stop.
> 
> - Samuli
> 
What is the problem with "default" in src_install?

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJPyx3BAAoJEPqDWhW0r/LCDU8P/0CAf/WNo/QXy4+sDWZ+yi1X
w3OYURV1MC31SvuzP2WLUruiMokDVe2n8h64yMG8F2/CCcPfBpKKF0mWZilx+F3O
+kDZLRBApf4sinuKLPkicGFaFQl21jYphTJPr6blaYf5VPZZp6/lgYR6Tj2R9a21
gj9evIg/GajZF+JBc3t/R7Ijw+W3DBvBokEmJ9RbPI05hvaAjFKK9tN1Sk2Hk/aq
ntKS1CDuD4JCQaJpSSvmKZZPotrddy/g0yTdfri8aol6hQXIfKxNoDW4DEwAMsAj
d1u92qi2Hwha3bK0OrruF5PTvGLdE7SSnQeM1dH+hASX35PXLqET4LE3j4DyCkJF
1ttlr9eTIqMSbqiYOZmxaDPJvmgIX8aWxKXnrRS+6jbua92xd7q2ZPdWFBVqSOuH
srSwNiJg3pAAgKy5IiJNfWP+TyAgSfZ9gqmJ8uX4MK56iIDT7JWBZ8nY+YPLdx4w
vOmsV90Yi20L7NsSP14Dlw1o1AHkoUWQdKC7jqRhYwuGnZ3VENNBMiOZ/G8ro6eY
1x3QoXlDCITKofU84F1Tot4yoztWdq/ry/sic29xQ8lJwiH6W8NRV+T7OcFsiPD2
ARoSnIhnDpEbOk8heg1CELTZyKXeZFKaqGdl1I/Sljv5Ai9iKslBOn8OjW5yiK2i
Cer7XXMkcBNjiw3aqSxC
=tpLH
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Ulrich Mueller]

>>>>> On Sun, 03 Jun 2012, Samuli Suominen wrote:
>>> this one is what I'm really after for:
>> 
>>> default for src_install() in EAPI=5 should accept "$@" in correct place
>>> to avoid usage of EXTRA_EMAKE within ebuilds/eclasses and to avoid
>>> duplicating the Portage code for DOCS.
>>> NOTE: When this was last voted on for EAPI=3, we didn't have this DOCS
>>> handling, and this wasn't important yet.
>> 
>>> emake DESTDIR="${D}" "$@" install
>> 
>> Again, this could be called directly, which has the advantage that it
>> makes it obvious that src_install isn't the default.

> The difference is working the tree when you have to alter ebuilds which 
> have been written like:

> DOCS=( AUTHORS README.NOW "${FILESDIR}"/README.Gentoo )

> src_install() {
> 	default
	
> 	echo "Some command here."
> }

> At this point you have to move content of DOCS which may or may not
> rely on the ""quoting with array"". Remove the call to default. And
> then duplicate the EAPI=4 default into the ebuild.

Why would you have to copy the EAPI 4 src_install code? Apart from
emake, you only need the single line:
   dodoc AUTHORS README.NOW "${FILESDIR}"/README.Gentoo
or
   dodoc "${DOCS[@]}"
if you want to keep the variable.

Ulrich

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Samuli Suominen]

On 06/03/2012 12:24 PM, Ulrich Mueller wrote:
>>>>>> On Sun, 03 Jun 2012, Samuli Suominen wrote:
>>>> this one is what I'm really after for:
>>>
>>>> default for src_install() in EAPI=5 should accept "$@" in correct place
>>>> to avoid usage of EXTRA_EMAKE within ebuilds/eclasses and to avoid
>>>> duplicating the Portage code for DOCS.
>>>> NOTE: When this was last voted on for EAPI=3, we didn't have this DOCS
>>>> handling, and this wasn't important yet.
>>>
>>>> emake DESTDIR="${D}" "$@" install
>>>
>>> Again, this could be called directly, which has the advantage that it
>>> makes it obvious that src_install isn't the default.
>
>> The difference is working the tree when you have to alter ebuilds which
>> have been written like:
>
>> DOCS=( AUTHORS README.NOW "${FILESDIR}"/README.Gentoo )
>
>> src_install() {
>> 	default
> 	
>> 	echo "Some command here."
>> }
>
>> At this point you have to move content of DOCS which may or may not
>> rely on the ""quoting with array"". Remove the call to default. And
>> then duplicate the EAPI=4 default into the ebuild.
>
> Why would you have to copy the EAPI 4 src_install code? Apart from
> emake, you only need the single line:
>     dodoc AUTHORS README.NOW "${FILESDIR}"/README.Gentoo
> or
>     dodoc "${DOCS[@]}"
> if you want to keep the variable.
>
> Ulrich
>

More like 2 lines, first one being the
s/default/emake DESTDIR="${D}" htmldir=/path/to/example install/
second one being the DOCS which might in an array or not, with or 
without quoting or * in place

Then do this multiple times by month all over the tree :/

And I did mention it makes the default EAPI=4 src_install() useless for 
eclasses due to lack of support for the arguments too?

When all there is required is dropping some "$@" to the Portage code and 
be done with it, and have everything be in consistent format...

- Samuli

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Samuli Suominen]

On 06/03/2012 11:18 AM, Markos Chandras wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 06/03/2012 04:26 AM, Samuli Suominen wrote:
>> On 06/03/2012 06:20 AM, Samuli Suominen wrote:
>>> On 06/03/2012 03:01 AM, Ulrich Mueller wrote:
>>>>>>>>> On Sun, 03 Jun 2012, Samuli Suominen wrote:
>>>>
>>>>>> On 05/29/2012 10:09 AM, Fabian Groffen wrote:
>>>>> http://archives.gentoo.org/gentoo-dev/msg_920c6d6daafe7702bfa3b8a2bc21e0c1.xml
>>>>>
>>>>>
>>>>
>>>>>>
>>>>>
> Can you indicate what the council has to vote on/decide for this one?
>>>>
>>>>> EAPI=5
>>>>
>>>>> optional: "$@" placement in default for src_configure()
>>>>
>>>>> econf "$@"
>>>>
>>>>> optional: "$@" placement in default for src_compile()
>>>>
>>>>> emake "$@"
>>>>
>>>> I still don't see the point of it. econf or emake could just be
>>>> called directly. We won't gain anything by allowing arguments,
>>>> but only complicate things.
>>>>
>>>>> this one is what I'm really after for:
>>>>
>>>>> default for src_install() in EAPI=5 should accept "$@" in
>>>>> correct place to avoid usage of EXTRA_EMAKE within
>>>>> ebuilds/eclasses and to avoid duplicating the Portage code
>>>>> for DOCS. NOTE: When this was last voted on for EAPI=3, we
>>>>> didn't have this DOCS handling, and this wasn't important
>>>>> yet.
>>>>
>>>>> emake DESTDIR="${D}" "$@" install
>>>>
>>>> Again, this could be called directly, which has the advantage
>>>> that it makes it obvious that src_install isn't the default.
>>>
>>> The difference is working the tree when you have to alter ebuilds
>>> which have been written like:
>>>
>>> DOCS=( AUTHORS README.NOW "${FILESDIR}"/README.Gentoo )
>>>
>>> src_install() { default
>>>
>>> echo "Some command here." }
>>>
>>> At this point you have to move content of DOCS which may or may
>>> not rely on the ""quoting with array"". Remove the call to
>>> default. And then duplicate the EAPI=4 default into the ebuild.
>>>
>>> And then replicate that every month dozen times and keep on doing
>>> it for some months. Get frustrated.
>>>
>>> If that's not enough, then you get all excited about EAPI=4 and
>>> finally think you have a replacement for base.eclass to port
>>> xfconf.eclass away from the thing when you only used it for
>>> default src_install() to avoid code duplication...
>>>
>>> Think you are all done, and then get complainment that support
>>> for extra arguments for xfconf_src_install was killed, and was
>>> required for things like:
>>>
>>> xfconf_src_install htmldirectory=/usr/share/doc/${PF}/html
>>> imagesdir=/usr/share/doc/${PF}/html/images
>>>
>>> Where sedding the build system runs maintainer mode at .in level,
>>> and runnning autotools (.am level) requires heavy documentation
>>> dependencies. You go back to base.eclass and get frustrated
>>> more.
>>>
>>> I hope that clears things up ;-)
>>>
>>
>> Also, if not implemented, what is the replacement for EXTRA_EMAKE
>> which we are allowed to use from ebuilds? Or are we allowed to use
>> it? I think PMS didn't forbid it the last time I checked and it has
>> consumers in tree already.
>>
>> And if not implemented, would the council please vote on banning
>> the usage of `default` in src_install() directly from ebuilds? The
>> syntax back and forth converting MUST stop.
>>
>> - Samuli
>>
> What is the problem with "default" in src_install?

Did you not read the mail at all? The lack of support for arguments 
makes it useless, and even harmful/annoying when you have to convert 
them constantly around the tree

-Samuli

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/03/2012 10:44 AM, Samuli Suominen wrote:
> On 06/03/2012 11:18 AM, Markos Chandras wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>> 
>> On 06/03/2012 04:26 AM, Samuli Suominen wrote:
>>> On 06/03/2012 06:20 AM, Samuli Suominen wrote:
>>>> On 06/03/2012 03:01 AM, Ulrich Mueller wrote:
>>>>>>>>>> On Sun, 03 Jun 2012, Samuli Suominen wrote:
>>>>> 
>>>>>>> On 05/29/2012 10:09 AM, Fabian Groffen wrote:
>>>>>> http://archives.gentoo.org/gentoo-dev/msg_920c6d6daafe7702bfa3b8a2bc21e0c1.xml
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>>>
>>>>>>
>>
>>>>>> 
Can you indicate what the council has to vote on/decide for this one?
>>>>> 
>>>>>> EAPI=5
>>>>> 
>>>>>> optional: "$@" placement in default for src_configure()
>>>>> 
>>>>>> econf "$@"
>>>>> 
>>>>>> optional: "$@" placement in default for src_compile()
>>>>> 
>>>>>> emake "$@"
>>>>> 
>>>>> I still don't see the point of it. econf or emake could
>>>>> just be called directly. We won't gain anything by allowing
>>>>> arguments, but only complicate things.
>>>>> 
>>>>>> this one is what I'm really after for:
>>>>> 
>>>>>> default for src_install() in EAPI=5 should accept "$@"
>>>>>> in correct place to avoid usage of EXTRA_EMAKE within 
>>>>>> ebuilds/eclasses and to avoid duplicating the Portage
>>>>>> code for DOCS. NOTE: When this was last voted on for
>>>>>> EAPI=3, we didn't have this DOCS handling, and this
>>>>>> wasn't important yet.
>>>>> 
>>>>>> emake DESTDIR="${D}" "$@" install
>>>>> 
>>>>> Again, this could be called directly, which has the
>>>>> advantage that it makes it obvious that src_install isn't
>>>>> the default.
>>>> 
>>>> The difference is working the tree when you have to alter
>>>> ebuilds which have been written like:
>>>> 
>>>> DOCS=( AUTHORS README.NOW "${FILESDIR}"/README.Gentoo )
>>>> 
>>>> src_install() { default
>>>> 
>>>> echo "Some command here." }
>>>> 
>>>> At this point you have to move content of DOCS which may or
>>>> may not rely on the ""quoting with array"". Remove the call
>>>> to default. And then duplicate the EAPI=4 default into the
>>>> ebuild.
>>>> 
>>>> And then replicate that every month dozen times and keep on
>>>> doing it for some months. Get frustrated.
>>>> 
>>>> If that's not enough, then you get all excited about EAPI=4
>>>> and finally think you have a replacement for base.eclass to
>>>> port xfconf.eclass away from the thing when you only used it
>>>> for default src_install() to avoid code duplication...
>>>> 
>>>> Think you are all done, and then get complainment that
>>>> support for extra arguments for xfconf_src_install was
>>>> killed, and was required for things like:
>>>> 
>>>> xfconf_src_install htmldirectory=/usr/share/doc/${PF}/html 
>>>> imagesdir=/usr/share/doc/${PF}/html/images
>>>> 
>>>> Where sedding the build system runs maintainer mode at .in
>>>> level, and runnning autotools (.am level) requires heavy
>>>> documentation dependencies. You go back to base.eclass and
>>>> get frustrated more.
>>>> 
>>>> I hope that clears things up ;-)
>>>> 
>>> 
>>> Also, if not implemented, what is the replacement for
>>> EXTRA_EMAKE which we are allowed to use from ebuilds? Or are we
>>> allowed to use it? I think PMS didn't forbid it the last time I
>>> checked and it has consumers in tree already.
>>> 
>>> And if not implemented, would the council please vote on
>>> banning the usage of `default` in src_install() directly from
>>> ebuilds? The syntax back and forth converting MUST stop.
>>> 
>>> - Samuli
>>> 
>> What is the problem with "default" in src_install?
> 
> Did you not read the mail at all? The lack of support for
> arguments makes it useless, and even harmful/annoying when you have
> to convert them constantly around the tree
> 
> -Samuli
> 
You don't have to be offensive. Of course I've read it. My point is
that if you use "default" in src_install, you need the default
function for that EAPI. If you want to override it then implement your
own email <foo> <bar> install line. I just don't understand why you
want us to ban it. Personally I find it useful to call "default" from
src_install.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJPy1eLAAoJEPqDWhW0r/LCHW8P/iJIY1I+s8Tn1qEcFj6ZUbXI
/QI7XPyDbaZMcr3XwoaYuxrj7QLx3XUipnutcSfZP9hLlLsVmYOf2OtBwJZyRpdr
wnxNXFh7yFkJncFjLIldvJ1be8eLaZmA+PnkzqIHc+mX+BpyP48ISF1CFQAwLAP5
llMGHV3DZ7C0Fw4p3qDsyohnL1wwNyC5e3Mq/rfuurddn0bN4aKwyKjVY5SBrt/+
xQQoXvTN/up8BcEllLEXGBmgp7aHVxUQR6guW4Q+j7sab6Lxn4HRzakwEYVeBB9K
PAe8V9OGRCXCZhVUUp8rNob8rJy2HRLT95yfV3qHYAsPDXxpiGMObafMR8bPhLiu
0Uq+4ODBJW49cTlpCv/jQ+ztHuM1aeZgy6kDurDpgGH+VeTZiG5bk7wVUdzsPZcx
g5GmYHLxBTT3sQ3ynntezTRLNg62UgfLdItIMe2INfNgf4FC6hlNgo53irNR+RrK
S8u11r9bLGmp84GbBPxJvhpbpcjS7lJfCgPQAVR8ZrV5NrgYiiCSd7Vl30l39iUR
Ltn/5A7DxlN0ua5X1sDp37Y0VPUoAtiL99hzFELCoRKV891zDlcDPhOajiBBDM+V
JHKsmT8ckIsjbCuN5EuSMSHnFDNGvsAoLauMMZXAbmNeNpSZ61VWBI/nipcC32i9
j8arDp1/i9aCctAy9jTC
=Dnf1
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Sun, 03 Jun 2012 12:42:45 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> When all there is required is dropping some "$@" to the Portage code
> and be done with it, and have everything be in consistent format...

The question is not about the code, but about the design. Your design
doesn't make sense: there's no direct correspondence between functions
and phases, so it's not obvious where arguments to "default" get sent.

"default" is for the easy cases. If you're wanting to do something
different, don't use it.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Sun, Jun 03, 2012 at 01:38:32PM +0100, Ciaran McCreesh wrote:
> On Sun, 03 Jun 2012 12:42:45 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> > When all there is required is dropping some "$@" to the Portage code
> > and be done with it, and have everything be in consistent format...
> 
> The question is not about the code, but about the design. Your design
> doesn't make sense: there's no direct correspondence between functions
> and phases, so it's not obvious where arguments to "default" get sent.
> 
> "default" is for the easy cases. If you're wanting to do something
> different, don't use it.

Also, default can be used as the starting point for a more complex
install. For example, you can call default, then once that returns,
modify the image by adding/removing/moving files, adding init scripts,
etc.

So I would also strongly disagree with a ban on calling default from the
install phase.

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12

[Samuli Suominen]

On 06/04/2012 02:23 AM, William Hubbs wrote:
> On Sun, Jun 03, 2012 at 01:38:32PM +0100, Ciaran McCreesh wrote:
>> On Sun, 03 Jun 2012 12:42:45 +0300
>> Samuli Suominen<ssuominen@gentoo.org>  wrote:
>>> When all there is required is dropping some "$@" to the Portage code
>>> and be done with it, and have everything be in consistent format...
>>
>> The question is not about the code, but about the design. Your design
>> doesn't make sense: there's no direct correspondence between functions
>> and phases, so it's not obvious where arguments to "default" get sent.
>>
>> "default" is for the easy cases. If you're wanting to do something
>> different, don't use it.
>
> Also, default can be used as the starting point for a more complex
> install. For example, you can call default, then once that returns,
> modify the image by adding/removing/moving files, adding init scripts,
> etc.

yeah, the default of EAPI=4 is nearly replacement for the src_install() 
provided by base.eclass
except it is missing argument handling

the number of pkgs using it are increasing steadily exactly for the 
reason you described, it is useful already, except when it's not anymore

would be cool to just point src_{configure,compile,install}() to 
`default` in, for example, xfconf.eclass and then do rest like you 
described, like:

xfconf_src_configure() {
[[ ${PV} == *9999* ]] && XFCONF+=( --enable-maintainer-mode )
default "${XFCONF[@]}" "$@"
}

xfconf_src_compile() {
default "$@"
}

xfconf_src_install() {
default "$@"
find "${ED}" -name '*.la' -exec rm -f {} +
validate_desktop_entries
}

we could even let base.eclass go at some point for most packages.
epatch_user and PATCHES=() to own eclass, like "patches.eclass", if you 
have better name idea, speak up.
then when EAPI=5 is released, convert packages using base.eclass from 
EAPI<5 + base.eclass, to EAPI=5 + patches.eclass