ebuild laziness and binpkg overhead
 

On Tue, 12 Jun 2012 23:02:40 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> i've noticed a growing trend where people put setup of variables into
> pkg_setup that only matter to src_* funcs presumably so they don't
> have to call the respective src_* func from an inherited eclass.
> unfortunately this adds pointless overhead to binpkgs. can we please
> move away from this practice ?

Like this?

* ERROR: cat/pkg-version failed (prepare phase):
* python_set_active_version() can be used only in pkg_setup() phase
*
* Call stack:
* ebuild.sh, line 85: Called src_prepare
* environment, line 5885: Called python_set_active_version '2'
* environment, line 5603: Called die
* The specific snippet of code:
* die "${FUNCNAME}() can be used only in pkg_setup() phase";
*

Shouldn't that be in src_prepare already, or does python.eclass do
something rather important here while installing a binpkg?


jer

ebuild laziness and binpkg overhead
 

On 06/15/2012 06:10 PM, Mike Frysinger wrote:

On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:

On 06/13/2012 06:02 AM, Mike Frysinger wrote:

i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't have
to call the respective src_* func from an inherited eclass.
unfortunately this adds pointless overhead to binpkgs. can we please
move away from this practice ?


Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
DOCS for src_install, PATCHES for src_prepare


these are static variables, so defining them in a func is pointless


"sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used
before, not sure if it's used in tree right now or not





and XFCONF for src_configure


now you're down to one variable which means you've got one func to /properly/
define


src_configure() still requires calling itself (xfconf_src_configure) in
the end of the function
someone suggested writing, for example, xfconf() function that accepts
$@ arguments so you could

src_configure() {
xfconf
$(use_enable foo)
}
but I don't really like that either...

src_setup() would be cool and solve all the forementioned issues

-Samuli

ebuild laziness and binpkg overhead
 

On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote:
> On 06/15/2012 06:10 PM, Mike Frysinger wrote:
> > On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:
> >> On 06/13/2012 06:02 AM, Mike Frysinger wrote:
> >>> i've noticed a growing trend where people put setup of variables into
> >>> pkg_setup that only matter to src_* funcs presumably so they don't have
> >>> to call the respective src_* func from an inherited eclass.
> >>> unfortunately this adds pointless overhead to binpkgs. can we please
> >>> move away from this practice ?
> >>
> >> Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
> >> DOCS for src_install, PATCHES for src_prepare
> >
> > these are static variables, so defining them in a func is pointless
>
> "sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used
> before, not sure if it's used in tree right now or not

as we've always said, USE conditional patches are to be highly discouraged

> >> and XFCONF for src_configure
> >
> > now you're down to one variable which means you've got one func to
> > /properly/ define
>
> src_configure() still requires calling itself (xfconf_src_configure) in
> the end of the function

yes, but that's the correct way to do it
-mike

ebuild laziness and binpkg overhead
 

On Tuesday 19 June 2012 17:35:00 Jeroen Roovers wrote:
> On Tue, 12 Jun 2012 23:02:40 -0400 Mike Frysinger wrote:
> > i've noticed a growing trend where people put setup of variables into
> > pkg_setup that only matter to src_* funcs presumably so they don't
> > have to call the respective src_* func from an inherited eclass.
> > unfortunately this adds pointless overhead to binpkgs. can we please
> > move away from this practice ?
>
> Like this?

not quite

> * ERROR: cat/pkg-version failed (prepare phase):
> * python_set_active_version() can be used only in pkg_setup() phase
> *
> * Call stack:
> * ebuild.sh, line 85: Called src_prepare
> * environment, line 5885: Called python_set_active_version '2'
> * environment, line 5603: Called die
> * The specific snippet of code:
> * die "${FUNCNAME}() can be used only in pkg_setup() phase";
> *
>
> Shouldn't that be in src_prepare already, or does python.eclass do
> something rather important here while installing a binpkg?

Gentoo's python integration is an ugly beast. in this case, i believe it's
screwing with your $ROOT which means it has to be in pkg_* (let's quietly
ignore what happens if you try to emerge two ebuilds which need conflicting
versions of python active).
-mike

ebuild laziness and binpkg overhead
 

On 06/20/2012 06:19 AM, Mike Frysinger wrote:

On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote:

On 06/15/2012 06:10 PM, Mike Frysinger wrote:

On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:

On 06/13/2012 06:02 AM, Mike Frysinger wrote:

i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't have
to call the respective src_* func from an inherited eclass.
unfortunately this adds pointless overhead to binpkgs. can we please
move away from this practice ?


Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
DOCS for src_install, PATCHES for src_prepare


these are static variables, so defining them in a func is pointless


"sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used
before, not sure if it's used in tree right now or not


as we've always said, USE conditional patches are to be highly discouraged


I agree BUT there are cases where it's OK to use conditional patching:

For example, libfoo-0.1.1 is broken and is fixed in git for master which
will be in next release. The fix doesn't apply to 0.1.1 cleanly without
heavy modifications.
Then you would take the easiest possible route to get 0.1.1 working
again, with the comfort of knowing it's properly fixed for the next version.


-Samuli

ebuild laziness and binpkg overhead
 

On Tue, Jun 19, 2012 at 10:27 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 06/20/2012 06:19 AM, Mike Frysinger wrote:
>>
>> On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote:
>>>
>>> On 06/15/2012 06:10 PM, Mike Frysinger wrote:
>>>>
>>>> On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:
>>>>>
>>>>> On 06/13/2012 06:02 AM, Mike Frysinger wrote:
>>>>>>
>>>>>> i've noticed a growing trend where people put setup of variables into
>>>>>> pkg_setup that only matter to src_* funcs presumably so they don't
>>>>>> have
>>>>>> to call the respective src_* func from an inherited eclass.
>>>>>> unfortunately this adds pointless overhead to binpkgs. *can we please
>>>>>> move away from this practice ?
>>>>>
>>>>>
>>>>> Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
>>>>> DOCS for src_install, PATCHES for src_prepare
>>>>
>>>>
>>>> these are static variables, so defining them in a func is pointless
>>>
>>>
>>> "sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used
>>> before, not sure if it's used in tree right now or not
>>
>>
>> as we've always said, USE conditional patches are to be highly discouraged
>
>
> I agree BUT there are cases where it's OK to use conditional patching:
>
> For example, libfoo-0.1.1 is broken and is fixed in git for master which
> will be in next release. The fix doesn't apply to 0.1.1 cleanly without
> heavy modifications.
> Then you would take the easiest possible route to get 0.1.1 working again,
> with the comfort of knowing it's properly fixed for the next version.
>
> -Samuli
>

I assume you mean libfoo-0.1.1 is broken when USE=bar is enabled and
you get a patch for that conditional case when USE=bar is enabled.

Either way, the better solution is to mask it and have people use libfoo-0.1.0

--
Doug Goldstein

ebuild laziness and binpkg overhead
 

On Tue, Jun 19, 2012 at 11:21 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 19 June 2012 17:35:00 Jeroen Roovers wrote:
>> On Tue, 12 Jun 2012 23:02:40 -0400 Mike Frysinger wrote:
>> > i've noticed a growing trend where people put setup of variables into
>> > pkg_setup that only matter to src_* funcs presumably so they don't
>> > have to call the respective src_* func from an inherited eclass.
>> > unfortunately this adds pointless overhead to binpkgs. *can we please
>> > move away from this practice ?
>>
>> Like this?
>
> not quite
>
>> ** ERROR: cat/pkg-version failed (prepare phase):
>> ** * python_set_active_version() can be used only in pkg_setup() phase
>> **
>> ** Call stack:
>> ** * * ebuild.sh, line * 85: *Called src_prepare
>> ** * environment, line 5885: *Called python_set_active_version '2'
>> ** * environment, line 5603: *Called die
>> ** The specific snippet of code:
>> ** * * * * * die "${FUNCNAME}() can be used only in pkg_setup() phase";
>> **
>>
>> Shouldn't that be in src_prepare already, or does python.eclass do
>> something rather important here while installing a binpkg?
>
> Gentoo's python integration is an ugly beast. *in this case, i believe it's
> screwing with your $ROOT which means it has to be in pkg_* (let's quietly
> ignore what happens if you try to emerge two ebuilds which need conflicting
> versions of python active).
> -mike

python_set_active_version basically just sets the EPYTHON and
PYTHON_ABI variables; nothing in ${ROOT} is modified.

The variables are used in python_pkg_setup to implement use-flag
checks for PYTHON_USE_WITH, and also in python_mod_optimize which is
called in pkg_postinst.

ebuild laziness and binpkg overhead
 

On 06/20/2012 06:46 AM, Doug Goldstein wrote:

On Tue, Jun 19, 2012 at 10:27 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:

On 06/20/2012 06:19 AM, Mike Frysinger wrote:


On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote:


On 06/15/2012 06:10 PM, Mike Frysinger wrote:


On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:


On 06/13/2012 06:02 AM, Mike Frysinger wrote:


i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't
have
to call the respective src_* func from an inherited eclass.
unfortunately this adds pointless overhead to binpkgs. can we please
move away from this practice ?



Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
DOCS for src_install, PATCHES for src_prepare



these are static variables, so defining them in a func is pointless



"sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used
before, not sure if it's used in tree right now or not



as we've always said, USE conditional patches are to be highly discouraged



I agree BUT there are cases where it's OK to use conditional patching:

For example, libfoo-0.1.1 is broken and is fixed in git for master which
will be in next release. The fix doesn't apply to 0.1.1 cleanly without
heavy modifications.
Then you would take the easiest possible route to get 0.1.1 working again,
with the comfort of knowing it's properly fixed for the next version.

-Samuli



I assume you mean libfoo-0.1.1 is broken when USE=bar is enabled and
you get a patch for that conditional case when USE=bar is enabled.


Right. Of course.


Either way, the better solution is to mask it and have people use libfoo-0.1.0



Doesn't really apply to this case:
Think about masking stable Xfce 4.10 when the fix is in git that will be
released as 4.12 in about year. ;-)


- Samuli

ebuild laziness and binpkg overhead
 

On Tuesday 19 June 2012 23:27:06 Samuli Suominen wrote:
> On 06/20/2012 06:19 AM, Mike Frysinger wrote:
> > On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote:
> >> On 06/15/2012 06:10 PM, Mike Frysinger wrote:
> >>> On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:
> >>>> On 06/13/2012 06:02 AM, Mike Frysinger wrote:
> >>>>> i've noticed a growing trend where people put setup of variables into
> >>>>> pkg_setup that only matter to src_* funcs presumably so they don't
> >>>>> have to call the respective src_* func from an inherited eclass.
> >>>>> unfortunately this adds pointless overhead to binpkgs. can we please
> >>>>> move away from this practice ?
> >>>>
> >>>> Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
> >>>> DOCS for src_install, PATCHES for src_prepare
> >>>
> >>> these are static variables, so defining them in a func is pointless
> >>
> >> "sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used
> >> before, not sure if it's used in tree right now or not
> >
> > as we've always said, USE conditional patches are to be highly
> > discouraged
>
> I agree BUT there are cases where it's OK to use conditional patching:
>
> For example, libfoo-0.1.1 is broken and is fixed in git for master which
> will be in next release. The fix doesn't apply to 0.1.1 cleanly without
> heavy modifications.
> Then you would take the easiest possible route to get 0.1.1 working
> again, with the comfort of knowing it's properly fixed for the next
> version.

hypothetical situations are great and all, but how many of those apply to the
ebuilds you're worried about ? i'd wager most do not. can we please fix the
majority here ? i'd be significantly less grumpy if we treated this as the
exception instead of the rule.
-mike

ebuild laziness and binpkg overhead
 

On Tuesday 19 June 2012 23:59:02 Mike Gilbert wrote:
> On Tue, Jun 19, 2012 at 11:21 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On Tuesday 19 June 2012 17:35:00 Jeroen Roovers wrote:
> >> On Tue, 12 Jun 2012 23:02:40 -0400 Mike Frysinger wrote:
> >> > i've noticed a growing trend where people put setup of variables into
> >> > pkg_setup that only matter to src_* funcs presumably so they don't
> >> > have to call the respective src_* func from an inherited eclass.
> >> > unfortunately this adds pointless overhead to binpkgs. can we please
> >> > move away from this practice ?
> >>
> >> Like this?
> >
> > not quite
> >
> >> * ERROR: cat/pkg-version failed (prepare phase):
> >> * python_set_active_version() can be used only in pkg_setup() phase
> >> *
> >> * Call stack:
> >> * ebuild.sh, line 85: Called src_prepare
> >> * environment, line 5885: Called python_set_active_version '2'
> >> * environment, line 5603: Called die
> >> * The specific snippet of code:
> >> * die "${FUNCNAME}() can be used only in pkg_setup() phase";
> >> *
> >>
> >> Shouldn't that be in src_prepare already, or does python.eclass do
> >> something rather important here while installing a binpkg?
> >
> > Gentoo's python integration is an ugly beast. in this case, i believe
> > it's screwing with your $ROOT which means it has to be in pkg_* (let's
> > quietly ignore what happens if you try to emerge two ebuilds which need
> > conflicting versions of python active).
>
> python_set_active_version basically just sets the EPYTHON and
> PYTHON_ABI variables; nothing in ${ROOT} is modified.

good to know

> The variables are used in python_pkg_setup to implement use-flag
> checks for PYTHON_USE_WITH, and also in python_mod_optimize which is
> called in pkg_postinst.

thx for the details
-mike