[gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
Hi, Petteri Räty : > If relevant people already know the policy and act accordingly then > why do we have this thread in the first place? Security is (as all the teams), badly understaffed, so sometimes something like this slips. It was a friendly reminder as it happens from time to time and slipping security bugs is the worst that can happen from an arch perspective. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-council] Upcoming Council meeting on July 26th, 1900 UTC
On Sun, Jul 18, 2010 at 06:21:03AM +0300, Theo Chatzimichos wrote: > On Sun, Jul 18, 2010 at 6:13 AM, Jorge Manuel B. S. Vicetto > wrote: > > I cross-posted this email to both gentoo-dev and gentoo-council mls as > > Brian used the former and Alex started this thread in the latter. Which > > ML do we want to use? > > I guess Brian posted on gentoo-dev as this usually happens with > threads that start on -dev-announce. I'd prefer you to use gentoo-dev > for such council meeting threads (pretty please) Generally seconded on that one. ~brian pgpljZAHJcRMM.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-council] Upcoming Council meeting on July 26th, 1900 UTC
On Sun, Jul 18, 2010 at 6:13 AM, Jorge Manuel B. S. Vicetto wrote: > I cross-posted this email to both gentoo-dev and gentoo-council mls as > Brian used the former and Alex started this thread in the latter. Which > ML do we want to use? I guess Brian posted on gentoo-dev as this usually happens with threads that start on -dev-announce. I'd prefer you to use gentoo-dev for such council meeting threads (pretty please)
Re: [gentoo-dev] Re: [gentoo-council] Upcoming Council meeting on July 26th, 1900 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-07-2010 23:33, Brian Harring wrote: > On Sun, Jul 18, 2010 at 01:05:02AM +0300, Alex Alexander wrote: >> The Council will have its next meeting on the 26th of July, 2010. >> >> The meeting will begin at 1900 UTC. >> >> You may use [0] to find out the correct time in your timezone. >> >> Here's a draft list of the meeting topics so far: >> * vote on adding --as-needed to the default profile's LDFLAGS >> * discuss (and maybe vote on) required-use >> http://dev.gentoo.org/~ferringb/required-use.html > > Adding eclass removal policy to the agenda; it directly affects devs, > and the previous policy (imo) is misinterpretted slightly. > > Specifically, 06/01/08, portage 2.1.4.4 went stable; this had env > saving/restoration support. The original council decree was that > eclasses had to sit for 2 years- I very strongly posit that the time > period there should've been bound to portage env capabilities rather > than eclass timelines. > > Reasoning is simple enough- w/ a proper PM, eclasses can be > removed/modified at will without affecting binpkgs/installed pkgs. > > So the question I'd like on the agenda is basically if there is any > reason to preserve the decree- if not, punt it. I would like to have the council discuss this issue again. We should probably also address the issue of EAPI changes in eclasses that was subject of a recent thread in the dev ml. > ~harring Let's add to the agenda the use of the invalid DEPEND atom "EAPI_TOO_OLD" instead of calling die in global scope on eclasses. I cross-posted this email to both gentoo-dev and gentoo-council mls as Brian used the former and Alex started this thread in the latter. Which ML do we want to use? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMQnFRAAoJEC8ZTXQF1qEPpFwP/2gvNqk4RIektsFEjJZ7NhIf OcOSgBVMHFyXv7CDVP0e39bdajcH0ll2pGHYRTSHbPN0SBUN56UguRrDnlUWTjCc DMAEd9Z4xkFh07BTiDiZI1w6tm0rkjxUV3NWpKQShAxJwDNXL6j5Qvdzy/ZJPFbB TZYWRRNLBJ5fbHyCHqp5yELbflETgO148o1INyPKBB2NtmdWGHXjPUZMLQOLV9Gg eE9btQ9EU2Xi8e9bqacThEoy1UuRoG4WXn3qpgpRLSZ9H84mAKJohFKCSyntgvgU J1AldKMRTbhB+CQZ+AUG6bCIG2mtFxiL5BtapUmRUo0P/jMtt+NXQ1WL5O8vOV7t J/tUz8C/kRx/I/IIQlYOv24ZgemC5waSlYOWFN8+f1gKou0Yent/GMb0QlIMrtrU 2Xx0OrbAT1JuNCobo3D9iDJsRAtOgUbg8JziUxidNwlpQqz9mgXcL7wHtBSqoYXX UDVYyoSZwv2xEZjdr1dUMe3oDHnawbnrPW4I4o7jkPgKoszd3T1pwR83lzWHb42m u5/YnSBtKP5dfGCEcAwVPgpG8xzYx3wcfI60tuDFxBIl8gAHrFgnDQgS3MDt+qPe Cu9Nr4hrbmBfLzwcqNbk8QiGbjUzBG2jtrWASD6QAhDhF+pow6d3nPWXPivnUJAz drTCQgdwR21TIg8LGfrY =N+f/ -END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: autotools-utils.eclass
On Sun, Jul 18, 2010 at 01:54:43AM +, Jorge Manuel B. S. Vicetto wrote: > this is being used in the tree already. Doesn't make it right ;) > IIRC, since the introduction of EAPI-2 in the tree, there were a few > solutions present to the dev ml and the one agreed by people was the > abuse of depend to have the PM fail on dependency resolution instead of > calling die on an eclass - which iirc is / was forbidden by PMS. PMS has no such restriction as far as I know (or can grep for). Regardless, if PMS *did* forbid die's in eclass global scope... pretty much it's there already (including for when EAPI isn't at the correct value). Basically, a die can be dealt with better than broken atom's- DEPEND=eapi-too-old definitely conflicts w/ PMS (invalid atom), if die does in this case... the lesser of two evils is die. If PMS doesn't conflict (which I'm pretty sure it doesn't), then that leaves die as the proper approach. > We can discuss the correctness of this use, but please take into account > it's already being used so until we have such a discussion we can't > "forbid" its use. Yes we can. The fact it slipped in via 3 places that no one noticed doesn't mean it's now considerable acceptable. This is part of what triggered my rant- the tree is large and vast, sometimes monsters manage to get added and lurk for a while. That doesn't make them defacto standard however. At the time of it's addition, it was invalid from the parsing standpoint- it shouldn't have been added in the first place because of that. As for converting it to die, that can be done _now_ without fallout- if anything was triggering that codepath bones should've been complaining about it (yet to hear any such complaints). ~harring pgp5soDC4D20f.pgp Description: PGP signature
Re: [gentoo-dev] New eclass: autotools-utils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18-07-2010 00:58, Brian Harring wrote:
> On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote:
>> case ${EAPI:-0} in
>> 2|3|4) ;;
>> *) DEPEND="EAPI-TOO-OLD" ;;
>> esac
>>
>> why not:
>>
>> case ${EAPI:-0} in
>> 0|1) DEPEND="EAPI-TOO-OLD" ;;
>> esac
Alexis,
the problem with your alternative is that it's "too clever" and won't
die/kill/stop the processing of the eclass for newer EAPIs that at any
point in time no one can be sure will be compatible with the current
eclass design.
That's why it has been agreed that eclasses should specifically list all
supported EAPI versions and die/kill/stop on all other EAPI versions.
> Do not go adding invalid DEPEND like that. Make the eclass die
> instead.
Brian,
this is being used in the tree already.
IIRC, since the introduction of EAPI-2 in the tree, there were a few
solutions present to the dev ml and the one agreed by people was the
abuse of depend to have the PM fail on dependency resolution instead of
calling die on an eclass - which iirc is / was forbidden by PMS.
We can discuss the correctness of this use, but please take into account
it's already being used so until we have such a discussion we can't
"forbid" its use.
grep EAPI-TOO-OLD $(portageq portdir)/eclass/*
/home/gentoo-cvs/gentoo-x86/eclass/kde4-functions.eclass: *)
DEPEND="EAPI-TOO-OLD" ;;
/home/gentoo-cvs/gentoo-x86/eclass/poppler.eclass:has 2 ${EAPI} ||
DEPEND="EAPI-TOO-OLD"
/home/gentoo-cvs/gentoo-x86/eclass/virtuoso.eclass: *)
DEPEND='EAPI-TOO-OLD' ;;
> Seriously, and this is a general rant based on several years of
> people adding stupid shit without considering the fallout:
>
> Whatever great new little trick you can think of for stuff like
> this... it's wrong. Use the mechanisms that exist. If policy
> forbids it, fix the policy, don't come up w/ "clever" hacks around
> it. Fix the core issue instead.
>
> Wouldn't surprise me if portage would accept this and run with it,
> blowing up at emerge time instead. Pkgcore and paludis however will
> give you the finger *very* quickly since that's not a valid atom.
> Don't piss on our parties w/ 'clever' tricks, do the right thing and
> use a die.
>
> People will move their ass a helluva lot quicker when their ebuild
> breaks than when bones has to go yelling both at the eclass author,
> and the devs in question about missing deps.
>
> Do not add this to the tree.
See above that this is already in the tree and has been for a few months
(years?)
> ~harring
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMQl7jAAoJEC8ZTXQF1qEPQuIQANWeUwpZFNfsY6wkDWCOI+xR
p4sYPRiHStY4nCJ6IZ/DGvBNnrvo+KDn3P5vT9uHT4x50cE5bYeyz4l+DCjXYtCp
ey7rGL3P7l9vNtf6Vg7+8imaGbgGnr2mZQ8Pmn1ZWXaYW8i2e5yyTeUpvqH3TH2v
ASKYIg5VlS3MeiP2unOQfuLXqRDcyXxMPnG6xj3pl2PpGMT3X+rAAkLDqGKRcZJj
7uA0oVUdjWM5HTKqZKYRbYpLo5veawVC+FMR4Z4DA6yhgtYsUQ+mTYnfjGgavCah
KU881TUaZQajDSXVK4m1V8q8Zg0ge0vjeXN15CPhPFfnSyCqf6GbkPZE7OjizJdu
vA8uoYjEMNXTAnE+TS1h18I+Cs3rL8CA+sxbHZgING5cfg8DtfRRW02zJzicaLxP
tIlotZpefEKWrTBKPrfGjhk0Te/IjvUAyLfx77Q5qqKxihBxy9T0DSe7TA0Azwkk
B9eW9Cn1UeoHeV1M+/kD4oXna+d66rOHLXP7LerQjm7ZqII5MwGRA7yC7RhGDyvO
oCsOCii9iuBR5n+qc8dvlN9oYyrVuDE22a4LsBGSXIse9Z8C1fBayUwYTkbAJLA0
uKqYvElfvJoH9hjJud01iQtQ7GxTEdlT0HaeV085Tvq6D/eoK1U+tGlTeFZXNkFb
+6R9ncUuA0AeKcfVvJ2P
=8vjx
-END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: autotools-utils.eclass
On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote:
> case ${EAPI:-0} in
> 2|3|4) ;;
> *) DEPEND="EAPI-TOO-OLD" ;;
> esac
>
> why not:
>
> case ${EAPI:-0} in
> 0|1) DEPEND="EAPI-TOO-OLD" ;;
> esac
Do not go adding invalid DEPEND like that. Make the eclass die
instead.
Seriously, and this is a general rant based on several years of
people adding stupid shit without considering the fallout:
Whatever great new little trick you can think of for stuff like
this... it's wrong. Use the mechanisms that exist. If policy
forbids it, fix the policy, don't come up w/ "clever" hacks around
it. Fix the core issue instead.
Wouldn't surprise me if portage would accept this and run with it,
blowing up at emerge time instead. Pkgcore and paludis however will
give you the finger *very* quickly since that's not a valid atom.
Don't piss on our parties w/ 'clever' tricks, do the right thing and
use a die.
People will move their ass a helluva lot quicker when their ebuild
breaks than when bones has to go yelling both at the eclass author,
and the devs in question about missing deps.
Do not add this to the tree.
~harring
pgpwTIv2AlnPf.pgp
Description: PGP signature
Re: [gentoo-dev] New eclass: autotools-utils.eclass
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND="EAPI-TOO-OLD" ;;
esac
why not:
case ${EAPI:-0} in
0|1) DEPEND="EAPI-TOO-OLD" ;;
esac
?
Alexis.
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-council] Upcoming Council meeting on July 26th, 1900 UTC
On Sun, Jul 18, 2010 at 01:05:02AM +0300, Alex Alexander wrote: > The Council will have its next meeting on the 26th of July, 2010. > > The meeting will begin at 1900 UTC. > > You may use [0] to find out the correct time in your timezone. > > Here's a draft list of the meeting topics so far: > * vote on adding --as-needed to the default profile's LDFLAGS > * discuss (and maybe vote on) required-use > http://dev.gentoo.org/~ferringb/required-use.html Adding eclass removal policy to the agenda; it directly affects devs, and the previous policy (imo) is misinterpretted slightly. Specifically, 06/01/08, portage 2.1.4.4 went stable; this had env saving/restoration support. The original council decree was that eclasses had to sit for 2 years- I very strongly posit that the time period there should've been bound to portage env capabilities rather than eclass timelines. Reasoning is simple enough- w/ a proper PM, eclasses can be removed/modified at will without affecting binpkgs/installed pkgs. So the question I'd like on the agenda is basically if there is any reason to preserve the decree- if not, punt it. ~harring pgpqSjDOQ4AC8.pgp Description: PGP signature
[gentoo-dev] Re: Last rites: eclass/php5_1.eclass
On Sat, 17 Jul 2010 22:23:03 +0200 Matti Bickel wrote: > On 07/17/2010 09:58 PM, Matti Bickel wrote: > > since there's no dev-lang/php-5.1* version in the tree anymore, this > > eclass is useless. It will be removed on 17th August 2010. > > I've just been told by scarabeus that eclass removal is a two years > minimum process. So it'll be removed 17th August 2012 and marked #...@dead > (deprived of functionality) in the next days. /me shakes his fist once again at the inanity of this policy. -- fonts, gcc-porting, and it's all by design toolchain, wxwidgetsto keep us from losing our minds @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: eclass/php5_1.eclass
On 07/17/2010 09:58 PM, Matti Bickel wrote: > since there's no dev-lang/php-5.1* version in the tree anymore, this > eclass is useless. It will be removed on 17th August 2010. I've just been told by scarabeus that eclass removal is a two years minimum process. So it'll be removed 17th August 2012 and marked #...@dead (deprived of functionality) in the next days. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: eclass/php5_1.eclass
Hi, since there's no dev-lang/php-5.1* version in the tree anymore, this eclass is useless. It will be removed on 17th August 2010. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
On 07/17/2010 07:58 PM, Petteri Räty wrote: >> As the CC'ing should be done by the security folks/the maintainer when a >> new ebuild is ready, I don't think it needs to be in devmanual. The >> relevant people should be aware of the process. >> > If relevant people already know the policy and act accordingly then why > do we have this thread in the first place? Dunno, I take it as a friendly reminder. People can slip up. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
On 07/17/2010 08:50 PM, Matti Bickel wrote: > On 07/17/2010 07:02 PM, Petteri Räty wrote: >>> Do stabilisations on the security bug so arch team members can skim >>> through their stabilisation list by just looking for secur...@g.o to >>> find the vulnerable packages. >>> >>> V-Li >>> >> >> If you want things to happen this way then it should be at least >> documented in the devmanual. > > It's in the security project's policy: > "once an ebuild is committed, evaluate what keywords are needed for the > fix ebuild and get arch-specific teams to test and mark the ebuild > stable on their architectures (arch-teams should be cc'd on the bug, as > well as releng during release preparation) and set status whiteboard to > stable" > http://www.gentoo.org/security/en/vulnerability-policy.xml, Chapter 4 > > As the CC'ing should be done by the security folks/the maintainer when a > new ebuild is ready, I don't think it needs to be in devmanual. The > relevant people should be aware of the process. > If relevant people already know the policy and act accordingly then why do we have this thread in the first place? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
On 07/17/2010 07:02 PM, Petteri Räty wrote: >> Do stabilisations on the security bug so arch team members can skim >> through their stabilisation list by just looking for secur...@g.o to >> find the vulnerable packages. >> >> V-Li >> > > If you want things to happen this way then it should be at least > documented in the devmanual. It's in the security project's policy: "once an ebuild is committed, evaluate what keywords are needed for the fix ebuild and get arch-specific teams to test and mark the ebuild stable on their architectures (arch-teams should be cc'd on the bug, as well as releng during release preparation) and set status whiteboard to stable" http://www.gentoo.org/security/en/vulnerability-policy.xml, Chapter 4 As the CC'ing should be done by the security folks/the maintainer when a new ebuild is ready, I don't think it needs to be in devmanual. The relevant people should be aware of the process. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
On 07/17/2010 05:51 PM, Christian Faulhammer wrote: > Hi, > > Thilo Bangert : >>> please avoid having stabilisation requests >>> like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a >>> security bug. That way, architecture teams may not see the severity >>> directly and it slips, leaving users with vulnerable versions longer >>> than needed. Thank you. >> >> perhaps it's a good idea to tell people what you expect of them >> instead. i presume just removing the blocker will not satisfy you. > > Do stabilisations on the security bug so arch team members can skim > through their stabilisation list by just looking for secur...@g.o to > find the vulnerable packages. > > V-Li > If you want things to happen this way then it should be at least documented in the devmanual. Regards, Petter signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
Hi, Thilo Bangert : > > please avoid having stabilisation requests > > like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a > > security bug. That way, architecture teams may not see the severity > > directly and it slips, leaving users with vulnerable versions longer > > than needed. Thank you. > > perhaps it's a good idea to tell people what you expect of them > instead. i presume just removing the blocker will not satisfy you. Do stabilisations on the security bug so arch team members can skim through their stabilisation list by just looking for secur...@g.o to find the vulnerable packages. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Security stabilisations
Christian Faulhammer said: > Hi, > > please avoid having stabilisation requests > like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a > security bug. That way, architecture teams may not see the severity > directly and it slips, leaving users with vulnerable versions longer > than needed. Thank you. perhaps it's a good idea to tell people what you expect of them instead. i presume just removing the blocker will not satisfy you. ;-) kind regards Thilo > > V-Li signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: autotools-utils.eclass
On Saturday 17 of July 2010 13:03:33 Petteri Räty wrote: > On 07/17/2010 01:53 PM, Maciej Mrozowski wrote: > > After gathering some feedback, after addressing reported issues, now I > > feel it's ready for public consumption. especially when static-libs is > > being used more and more often. It's purpose is to become standard > > eclass for autotools build systems. > > > > Brief description: > > autotools-utils.eclass is autotools.eclass (so libtool.eclass) and > > base.eclass (so eutils.eclass) wrapper providing all inherited features > > (it is guaranteed, no need to additionally inherit any of those) along > > with econf arguments as Bash array, out of source build with overridable > > build dir location, static archives handling, libtool files removal, > > enable/disable debug handling. It's modelled after cmake-utils and > > resembles it in many aspects for consistency. > > Maybe choose some other name. For me -utils in an eclass name means a > set of helper functions. I would name it so the name reflects that it's > meant to be used as the main build system provider. It's for consistency with existing cmake-utils.eclass, which is main cmake buildsystem provider (no idea why it wasn't called just 'cmake' by initial commiters). Unfortunately autotools name is already taken and extending autotools so much (adding new defined phases) is not possible (nor is renaming) as far as I understand. -- regards MM
Re: [gentoo-dev] New eclass: autotools-utils.eclass
On 07/17/2010 01:53 PM, Maciej Mrozowski wrote: > After gathering some feedback, after addressing reported issues, now I feel > it's ready for public consumption. especially when static-libs is being used > more and more often. It's purpose is to become standard eclass for autotools > build systems. > > Brief description: > autotools-utils.eclass is autotools.eclass (so libtool.eclass) and > base.eclass > (so eutils.eclass) wrapper providing all inherited features (it is > guaranteed, > no need to additionally inherit any of those) along with econf arguments as > Bash array, out of source build with overridable build dir location, static > archives handling, libtool files removal, enable/disable debug handling. It's > modelled after cmake-utils and resembles it in many aspects for consistency. > Maybe choose some other name. For me -utils in an eclass name means a set of helper functions. I would name it so the name reflects that it's meant to be used as the main build system provider. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] New eclass: autotools-utils.eclass
After gathering some feedback, after addressing reported issues, now I feel
it's ready for public consumption. especially when static-libs is being used
more and more often. It's purpose is to become standard eclass for autotools
build systems.
Brief description:
autotools-utils.eclass is autotools.eclass (so libtool.eclass) and base.eclass
(so eutils.eclass) wrapper providing all inherited features (it is guaranteed,
no need to additionally inherit any of those) along with econf arguments as
Bash array, out of source build with overridable build dir location, static
archives handling, libtool files removal, enable/disable debug handling. It's
modelled after cmake-utils and resembles it in many aspects for consistency.
Notable features:
- eautoreconf, eautomake, elibtoolize, eaclocal functions (from autotools)
- PATCHES and user patches support (from base)
- DOCS and HTML_DOCS arrays support (from base)
- myeconfargs - econf arguments as Bash array (usage like mycmakeargs in
cmake-utils, if used, needs to be defined just before autotools-
utils_src_configure call)
- out of source build (enabled by default) with overridable build dir location
- static archives handling (static-libs in IUSE)
- automatic removal of unnecessary static archives (usually for plugins,
determined by presence of shouldnotlink=yes libtool property)
- libtool files removal (static-libs in IUSE, determined by absence of
shouldnotlink=yes libtool property)
- enable/disable-debug handing (debug in IUSE)
- remove_libtool_files function to help override libtool removal behaviour
(you shouldn't need it, any usage or this function with parameter 'none' will
be reported and punished :p)
Restrictions:
- only >= EAPI-2 supported (this is intentional as src_prepare phase is
provided, EAPI-0,1 would mean providing src_unpack as well, which is
unacceptable for build system eclasses)
Attached two example ebuilds.
Refer to eclass manual page for details or more extensive example usage.
--
regards
MM
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# Maciej Mrozowski
# @BLURB: common ebuild functions for autotools-based packages
# @DESCRIPTION:
# autotools-utils.eclass is autotools.eclass(5) and base.eclass(5) wrapper
# providing all inherited features along with econf arguments as Bash array,
# out of source build with overridable build dir location, static archives
# handling, libtool files removal, enable/disable debug handling.
#
# @EXAMPLE:
# Typical ebuild using autotools-utils.eclass:
#
# @CODE
# EAPI="2"
#
# inherit autotools-utils
#
# DESCRIPTION="Foo bar application"
# HOMEPAGE="http://example.org/foo/";
# SRC_URI="mirror://sourceforge/foo/${P}.tar.bz2"
#
# LICENSE="LGPL-2.1"
# KEYWORDS=""
# SLOT="0"
# IUSE="debug doc examples qt4 static-libs tiff"
#
# CDEPEND="
# media-libs/libpng:0
# qt4? (
# x11-libs/qt-core:4
# x11-libs/qt-gui:4
# )
# tiff? ( media-libs/tiff:0 )
# "
# RDEPEND="${CDEPEND}
# !media-gfx/bar
# "
# DEPEND="${CDEPEND}
# doc? ( app-doc/doxygen )
# "
#
# # bug 123456
# AUTOTOOLS_IN_SOURCE_BUILD=1
#
# DOCS=(AUTHORS ChangeLog README "Read me.txt" TODO)
#
# PATCHES=(
# "${FILESDIR}/${P}-gcc44.patch" # bug 123458
# "${FILESDIR}/${P}-as-needed.patch"
# "${FILESDIR}/${P}-unbundle_libpng.patch"
# )
#
# src_configure() {
# myeconfargs=(
# $(use_with qt4)
# $(use_enable threads multithreading)
# $(use_with tiff)
# )
# autotools-utils_src_configure
# }
#
# src_compile() {
# autotools-utils_src_compile
# use doc && autotools-utils_src_compile docs
# }
#
# src_install() {
# use doc && HTML_DOCS=("${AUTOTOOLS_BUILD_DIR}/apidocs/html/")
# autotools-utils_src_install
# if use examples; then
# dobin "${AUTOTOOLS_BUILD_DIR}"/foo_example{1,2,3} \\
# || die 'dobin examples failed'
# fi
# }
#
# @CODE
# Keep variable names synced with cmake-utils and the other way around!
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND="EAPI-TOO-OLD" ;;
esac
inherit autotools base
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Build directory, location where all autotools generated files should be
# placed. For out of source builds it defaults to ${WORKDIR}/${P}_build.
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.
# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Specify location of autotools' configure script. By default it uses ${S}.
# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# Optional econf arguments as Bash array. Should be defined before calling
src_configure.
# @CODE
# src_configure() {
# myeconfargs=(
# --disable-readline
#
