Re: [gentoo-dev] 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 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 vap...@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
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tue, 12 Jun 2012 23:02:40 -0400
Mike Frysinger vap...@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
Re: [gentoo-dev] 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
Re: [gentoo-dev] 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 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
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] 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
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tue, Jun 19, 2012 at 10:27 PM, Samuli Suominen ssuomi...@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
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tue, Jun 19, 2012 at 11:21 PM, Mike Frysinger vap...@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.
Re: [gentoo-dev] 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 ssuomi...@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
Re: [gentoo-dev] ebuild laziness and binpkg overhead
Le vendredi 15 juin 2012 à 21:04 +0200, Pacho Ramos a écrit : El vie, 15-06-2012 a las 09:03 +0200, Pacho Ramos escribió: El mar, 12-06-2012 a las 23:02 -0400, Mike Frysinger escribió: 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 ? i've seen this with a good number of the GNOME packages like: [...] This is most likely historic and reading the eclasses, I see no use of G2CONF that would forbid working from src_configure. I guess the pratice emerged from not wanting to write gnome2_src_configure all the time but if there is a reason (like the one you exposed) to do it this way, then it'll become our new standard pratice :) -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ebuild laziness and binpkg overhead
Anything build-time related should not be placed into pkg_setup (I am pointing the finger to those build-related die() that are breaking binpkgs support). There's src_prepare() and src_configure() nowadays. -- Fabio Erculiani
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/16/2012 02:21 PM, Fabio Erculiani wrote: Anything build-time related should not be placed into pkg_setup (I am That is propably not very accurate statement, like with placing the call to `enewuser` when you need the user at src_configure(), src_compile() etc. pointing the finger to those build-related die() that are breaking binpkgs support). There's src_prepare() and src_configure() nowadays. Yeah, dying in pkg_setup() is most often not the way to go
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/16/2012 01:05 PM, Gilles Dartiguelongue wrote: Le vendredi 15 juin 2012 à 21:04 +0200, Pacho Ramos a écrit : El vie, 15-06-2012 a las 09:03 +0200, Pacho Ramos escribió: El mar, 12-06-2012 a las 23:02 -0400, Mike Frysinger escribió: 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 ? i've seen this with a good number of the GNOME packages like: [...] This is most likely historic and reading the eclasses, I see no use of G2CONF that would forbid working from src_configure. I guess the pratice emerged from not wanting to write gnome2_src_configure all the timebut if there is a reason (like the one you exposed) to do it this way, then it'll become our new standard pratice :) That is a quite bottleneck, at least for me. I don't think this issue is solvable without creating an new function to pass the vars across functions (phases) that has no existing content that would require calling itself at the end, like for example, src_setup()
Re: [gentoo-dev] ebuild laziness and binpkg overhead
El mar, 12-06-2012 a las 23:02 -0400, Mike Frysinger escribió:
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 ?
i've seen this with a good number of the GNOME packages like:
pkg_setup() {
G2CONF=${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)
}
ugh
-mike
Will CC the rest of gnome team because I thought this way of passing
configure options were intentional for some reason (or, at least, I
remember being using it for a looong time)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] ebuild laziness and binpkg overhead
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 ?
i've seen this with a good number of the GNOME packages like:
pkg_setup() {
G2CONF=${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)
}
ugh
-mike
Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
DOCS for src_install, PATCHES for src_prepare, and XFCONF for src_configure
No way we will add all 3 phases to every Xfce ebuild since that would
defeat the purpose of the xfconf.eclass which is designed so that we
cope with 99,0% using just pkg_setup()
Using all 3 vars would also likely mean that the diff's for xfce-overlay
for ebuilds would increase to unmaintainable stage (the
ebuilds are generated from gentoo-x86, not the otherway around)
The pros overweight the cons * N
- Samuli
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/15/2012 10:44 AM, Samuli Suominen wrote: Using all 3 vars would also likely mean that the diff's for xfce-overlay * vars - phases silly typing error. sorry.
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/15/2012 09:44 AM, Samuli Suominen wrote: Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, DOCS for src_install, PATCHES for src_prepare, and XFCONF for src_configure No way we will add all 3 phases to every Xfce ebuild since that would defeat the purpose of the xfconf.eclass which is designed so that we cope with 99,0% using just pkg_setup() defining a function and call it from the eclass would be impossible? lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Fri, 15 Jun 2012 14:24:54 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 06/15/2012 09:44 AM, Samuli Suominen wrote: Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, DOCS for src_install, PATCHES for src_prepare, and XFCONF for src_configure No way we will add all 3 phases to every Xfce ebuild since that would defeat the purpose of the xfconf.eclass which is designed so that we cope with 99,0% using just pkg_setup() defining a function and call it from the eclass would be impossible? Sounds like quite a good solution. We may also consider defining src_setup() in new EAPI. Of course, still going this way we'll end up with src_phase00(), src_phase40() and so on... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] ebuild laziness and binpkg overhead
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 and XFCONF for src_configure now you're down to one variable which means you've got one func to /properly/ define -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ebuild laziness and binpkg overhead
El vie, 15-06-2012 a las 09:03 +0200, Pacho Ramos escribió:
El mar, 12-06-2012 a las 23:02 -0400, Mike Frysinger escribió:
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 ?
i've seen this with a good number of the GNOME packages like:
pkg_setup() {
G2CONF=${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)
}
ugh
-mike
Will CC the rest of gnome team because I thought this way of passing
configure options were intentional for some reason (or, at least, I
remember being using it for a looong time)
I forgot to CC :S
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] ebuild laziness and binpkg overhead
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 ?
i've seen this with a good number of the GNOME packages like:
pkg_setup() {
G2CONF=${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)
}
ugh
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] ebuild laziness and binpkg overhead
Calling use in global scope isn't allowed so what are you suggesting
they do instead?
On Tue, Jun 12, 2012 at 11:02 PM, Mike Frysinger vap...@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 ?
i've seen this with a good number of the GNOME packages like:
pkg_setup() {
G2CONF=${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)
}
ugh
-mike
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 2012-06-12 Tue 20:20, Michael Sterrett wrote:
Calling use in global scope isn't allowed so what are you suggesting
they do instead?
Can't they just do something similar to how most cmake-utils and
autotools-utils users do things? For example:
src_configure() {
G2CONF=${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)
gnome2_src_configure
}
Seems like that should work fine.
Tim
pgptmeIZLBJc0.pgp
Description: PGP signature
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tuesday 12 June 2012 23:20:53 Michael Sterrett wrote: Calling use in global scope isn't allowed so what are you suggesting they do instead? as implied in the body of my message, put it into the relevant src_* func. in this case, src_prepare. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tuesday 12 June 2012 23:54:45 Mike Frysinger wrote: On Tuesday 12 June 2012 23:20:53 Michael Sterrett wrote: Calling use in global scope isn't allowed so what are you suggesting they do instead? as implied in the body of my message, put it into the relevant src_* func. in this case, src_prepare. err i meant src_configure :P. the ebuild i took this from defined a src_prepare already. -mike signature.asc Description: This is a digitally signed message part.
