[gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Samuli Suominen]

Example,

- Package is using autotools.
- The default phase like below works for the package:

src_install() {
emake DESTDIR="${D}" install
dodoc README
}

So when writing a new ebuild you would only add:

DOCS="README"

And be done with it. Then the next version of the package needs extra 
argument passed to emake install, for example:

src_install() {
emake DESTDIR="${D}" init_d_path="/usr/share/doc/${PF}/examples" install
dodoc README
}

So you are /forced/ to write entire src_install() while you only want to 
append one argument to emake install.

The current workaround for this is to use EXTRA_EMAKE from ebuild, but I 
find this rather ugly (if not even forbidden by some PMS magic?)

Can we make econf in src_configure, emake in src_compile, and emake 
install in src_install accept arguments "$@" in EAPI=5, please?

Relavent bug is http://bugs.gentoo.org/364343

- Samuli

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Ulrich Mueller]

>>>>> On Sat, 12 May 2012, Samuli Suominen wrote:

> Example,
> - Package is using autotools.
> - The default phase like below works for the package:

> src_install() {
> emake DESTDIR="${D}" install
> dodoc README
> }

> So when writing a new ebuild you would only add:

> DOCS="README"

> And be done with it. Then the next version of the package needs extra 
> argument passed to emake install, for example:

> src_install() {
> emake DESTDIR="${D}" init_d_path="/usr/share/doc/${PF}/examples" install
> dodoc README
> }

> So you are /forced/ to write entire src_install() while you only want to 
> append one argument to emake install.

> The current workaround for this is to use EXTRA_EMAKE from ebuild, but I 
> find this rather ugly (if not even forbidden by some PMS magic?)

EXTRA_EMAKE isn't mentioned by the PMS. Do all package managers
support this variable? Portage does since 2004 at least.

> Can we make econf in src_configure, emake in src_compile, and emake 
> install in src_install accept arguments "$@" in EAPI=5, please?

I'd rather document EXTRA_EMAKE and EXTRA_ECONF in the spec, either
retroactively (in case all package managers support these variables
already), or for EAPI 5. It would accomplish the same as your
proposal, even without the need to add an explicit src_install
function.

> Relavent bug is http://bugs.gentoo.org/364343

Ulrich

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Michał Górny]

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

On Sat, 12 May 2012 19:57:07 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> > The current workaround for this is to use EXTRA_EMAKE from ebuild,
> > but I find this rather ugly (if not even forbidden by some PMS
> > magic?)
> 
> EXTRA_EMAKE isn't mentioned by the PMS. Do all package managers
> support this variable? Portage does since 2004 at least.

EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use
variable for users who need to pass something specific to make.

> > Can we make econf in src_configure, emake in src_compile, and emake 
> > install in src_install accept arguments "$@" in EAPI=5, please?
> 
> I'd rather document EXTRA_EMAKE and EXTRA_ECONF in the spec, either
> retroactively (in case all package managers support these variables
> already), or for EAPI 5. It would accomplish the same as your
> proposal, even without the need to add an explicit src_install
> function.

As above. Otherwise, we'll end up reimplementing just another variable
to let users pass their custom arguments.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Samuli Suominen]

On 05/12/2012 09:09 PM, Michał Górny wrote:
> On Sat, 12 May 2012 19:57:07 +0200
> Ulrich Mueller<ulm@gentoo.org>  wrote:
>
>>> The current workaround for this is to use EXTRA_EMAKE from ebuild,
>>> but I find this rather ugly (if not even forbidden by some PMS
>>> magic?)
>>
>> EXTRA_EMAKE isn't mentioned by the PMS. Do all package managers
>> support this variable? Portage does since 2004 at least.
>
> EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use
> variable for users who need to pass something specific to make.
>
>>> Can we make econf in src_configure, emake in src_compile, and emake
>>> install in src_install accept arguments "$@" in EAPI=5, please?
>>
>> I'd rather document EXTRA_EMAKE and EXTRA_ECONF in the spec, either
>> retroactively (in case all package managers support these variables
>> already), or for EAPI 5. It would accomplish the same as your
>> proposal, even without the need to add an explicit src_install
>> function.
>
> As above. Otherwise, we'll end up reimplementing just another variable
> to let users pass their custom arguments.
>

Yeah, I think we should keep these EXTRA_* for users only and have 
something else for the ebuilds

(And I'm sure I don't remember wrong by saying some people have quite 
passionately resisted using EXTRA_ECONF within an ebuild in the past for 
this exact reasoning)

- Samuli

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Ulrich Mueller]

>>>>> On Sat, 12 May 2012, Michał Górny wrote:

> On Sat, 12 May 2012 19:57:07 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:

>> > The current workaround for this is to use EXTRA_EMAKE from ebuild,
>> > but I find this rather ugly (if not even forbidden by some PMS
>> > magic?)
>> 
>> EXTRA_EMAKE isn't mentioned by the PMS. Do all package managers
>> support this variable? Portage does since 2004 at least.

> EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use
> variable for users who need to pass something specific to make.

You are right, of course. (And this had been clarified before:
<http://archives.gentoo.org/gentoo-dev/msg_3d25b75236fe4d1e8008998e14fea164.xml>)

I guess the following ebuilds should be fixed then:

   eclass/bsdmk.eclass
   eclass/python.eclass
   eclass/scons-utils.eclass
   dev-db/redis/redis-2.2.12.ebuild
   dev-db/redis/redis-2.4.4-r1.ebuild
   dev-db/redis/redis-2.4.7.ebuild
   dev-db/redis/redis-2.4.8.ebuild
   dev-db/redis/redis-2.4.10.ebuild
   dev-db/redis/redis-2.4.13.ebuild
   gnome-base/gconf/gconf-2.32.4.ebuild
   net-misc/mico/mico-2.3.13-r5.ebuild
   sci-chemistry/ccp4-apps/ccp4-apps-6.1.3-r10.ebuild
   sys-fs/udev/udev-171-r5.ebuild

Ulrich

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[julian]

On 05/12/2012 06:50 PM, Samuli Suominen wrote:
> Example,
> 
> - Package is using autotools.
> - The default phase like below works for the package:
> 
> src_install() {
> emake DESTDIR="${D}" install
> dodoc README
> }
> 
> So when writing a new ebuild you would only add:
> 
> DOCS="README"
> 
> And be done with it. Then the next version of the package needs extra
> argument passed to emake install, for example:
> 
> src_install() {
> emake DESTDIR="${D}" init_d_path="/usr/share/doc/${PF}/examples" install
> dodoc README
> }
> 
> So you are /forced/ to write entire src_install() while you only want to
> append one argument to emake install.
> 
> The current workaround for this is to use EXTRA_EMAKE from ebuild, but I
> find this rather ugly (if not even forbidden by some PMS magic?)
> 
> Can we make econf in src_configure, emake in src_compile, and emake
> install in src_install accept arguments "$@" in EAPI=5, please?
> 
> Relavent bug is http://bugs.gentoo.org/364343
> 
> - Samuli
> 

I find this a good idea and since it's optional it does not add
unnecessary complexity.

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[hasufell]

On 05/12/2012 06:50 PM, Samuli Suominen wrote:
> Example,
> 
> - Package is using autotools.
> - The default phase like below works for the package:
> 
> src_install() {
> emake DESTDIR="${D}" install
> dodoc README
> }
> 
> So when writing a new ebuild you would only add:
> 
> DOCS="README"
> 
> And be done with it. Then the next version of the package needs extra
> argument passed to emake install, for example:
> 
> src_install() {
> emake DESTDIR="${D}" init_d_path="/usr/share/doc/${PF}/examples" install
> dodoc README
> }
> 
> So you are /forced/ to write entire src_install() while you only want to
> append one argument to emake install.
> 
> The current workaround for this is to use EXTRA_EMAKE from ebuild, but I
> find this rather ugly (if not even forbidden by some PMS magic?)
> 
> Can we make econf in src_configure, emake in src_compile, and emake
> install in src_install accept arguments "$@" in EAPI=5, please?
> 
> Relavent bug is http://bugs.gentoo.org/364343
> 
> - Samuli
> 

I find this a good idea and since it's optional it does not add
unnecessary complexity.

[gentoo-dev] Re: Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Duncan]

Ulrich Mueller posted on Sat, 12 May 2012 20:39:05 +0200 as excerpted:

> On Sat, 12 May 2012, Michał Górny wrote:
> 
>> EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use
>> variable for users who need to pass something specific to make.
> 
> You are right, of course.

> I guess the following ebuilds should be fixed then:
> 
>    eclass/bsdmk.eclass
>    eclass/python.eclass
>    eclass/scons-utils.eclass
>    dev-db/redis/redis-2.2.12.ebuild
>    dev-db/redis/redis-2.4.4-r1.ebuild
>    dev-db/redis/redis-2.4.7.ebuild
>    dev-db/redis/redis-2.4.8.ebuild
>    dev-db/redis/redis-2.4.10.ebuild
>    dev-db/redis/redis-2.4.13.ebuild
>    gnome-base/gconf/gconf-2.32.4.ebuild
>    net-misc/mico/mico-2.3.13-r5.ebuild
>    sci-chemistry/ccp4-apps/ccp4-apps-6.1.3-r10.ebuild
>    sys-fs/udev/udev-171-r5.ebuild

Ouch, in eclasses too!  Yes.  If I came across that I'd have filed bugs 
immediately, as I actually use EXTRA_* occasionally as a user, myself!  
Of course there's also the other PM users who would find these bugs.

Is someone else filing bugs, or should I?  Probably a tracker, along with 
individual bugs (only one for redis, tho)?

What about a repoman check?  Bug for that too?

(If the answer is me do it, please bump me in say 10 days or so if I 
don't.  I'm having stability problems on my main machine right now. ATA 
resets and I've already switched sata card and hard drive. Probably time 
for a new mobo/cpus/etc, but no $$ for it. =:^(  I may end up netbook-
only, severely restricting gentoo upgrades for awhile!)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Arfrever Frehtes Taifersar Arahesis]

2012-05-14 06:58:30 Duncan napisał(a):
> Ulrich Mueller posted on Sat, 12 May 2012 20:39:05 +0200 as excerpted:
> 
> > On Sat, 12 May 2012, Michał Górny wrote:
> > 
> >> EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use
> >> variable for users who need to pass something specific to make.
> > 
> > You are right, of course.
> 
> > I guess the following ebuilds should be fixed then:
> > 
> >    eclass/bsdmk.eclass
> >    eclass/python.eclass
> >    eclass/scons-utils.eclass
> >    dev-db/redis/redis-2.2.12.ebuild
> >    dev-db/redis/redis-2.4.4-r1.ebuild
> >    dev-db/redis/redis-2.4.7.ebuild
> >    dev-db/redis/redis-2.4.8.ebuild
> >    dev-db/redis/redis-2.4.10.ebuild
> >    dev-db/redis/redis-2.4.13.ebuild
> >    gnome-base/gconf/gconf-2.32.4.ebuild
> >    net-misc/mico/mico-2.3.13-r5.ebuild
> >    sci-chemistry/ccp4-apps/ccp4-apps-6.1.3-r10.ebuild
> >    sys-fs/udev/udev-171-r5.ebuild
> 
> Ouch, in eclasses too!

All matches in eclasses and some matches in ebuilds are false positives.

-- 
Arfrever Frehtes Taifersar Arahesis