On Sun, Jul 8, 2012 at 1:54 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 08 Jul 2012 19:49:25 +0200
> René Neumann <lists@necoro.eu> wrote:
>> I'd like just to receive a short clarification about the 'status' of
>> base.eclass: Is this eclass expected to be available everywhere, i.e.
>> should each eclass make sure it imports and incorporates it. Or is it
>> just an eclass like the others and ebuilds should make sure they
>> inherit it if needed?
>
> base.eclass is a historical mistake, from before the design of eclasses
> was fully figured out and moved into the package manager. Unfortunately,
> rather than letting it die, people keep putting things in it and using
> it...
I think it would be a good idea to remove the second sentence of the
description, which is clearly false.
# @DESCRIPTION:
# The base eclass defines some default functions and variables. Nearly
# everything else inherits from here.
> Hi all,
>
> I'd like just to receive a short clarification about the 'status' of
> base.eclass: Is this eclass expected to be available everywhere, i.e.
> should each eclass make sure it imports and incorporates it. Or is it
> just an eclass like the others and ebuilds should make sure they
> inherit it if needed?
No. It is unmaintained, has serious design flaws and it simply should
not be used anywhere. At least in EAPI != [01].
Thanks for the clarification. As Mike already mentioned, one should
probably change the ebuild description to reflect just that fact.
(Because at the moment it just says the complete opposite.)
A lot of (inheriting eclasses and) packages depend on features provided by
base.eclass (e.g., PATCHES), which are pretty neat and which I would sorely
miss. So I would certainly object to deprecating base.eclass, unless its
relevant functionality is only moving to a better place.
--
Andreas K. Huettel
Gentoo Linux developer
dilfridge@gentoo.org
http://www.akhuettel.de/
base.eclass is randomly exporting non-requested, non-wanted phase
functions colliding with other inherited eclasses. It's just
the lexical order of inherits what stops mayhem from happening.
In other words, base.eclass is only suitable if you are expecting to
export *all* phase functions which simply doesn't happen in eclasses.
For example, if distutils used base eclass, every VCS eclass inherited
before it would be ignored (due to src_unpack() redefined to default
one for no good reason).
--
Best regards,
Michał Górny
07-09-2012, 07:02 AM
Ciaran McCreesh
base.eclass
On Sun, 8 Jul 2012 23:40:29 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> A lot of (inheriting eclasses and) packages depend on features
> provided by base.eclass (e.g., PATCHES), which are pretty neat and
> which I would sorely miss. So I would certainly object to deprecating
> base.eclass, unless its relevant functionality is only moving to a
> better place.
Then you should ask for EAPI support for PATCHES, or write the code
manually, or put the code in a small eclass that just does that.
But note that the Council has voted against having either arguments or
global scope variables to enhance default phase functions.
I'd like just to receive a short clarification about the 'status' of
base.eclass: Is this eclass expected to be available everywhere, i.e.
should each eclass make sure it imports and incorporates it. Or is it
just an eclass like the others and ebuilds should make sure they
inherit it if needed?
No. It is unmaintained, has serious design flaws and it simply should
not be used anywhere. At least in EAPI != [01].
yet base.eclass supports arguments for base_src_install passed to 'make
install'
and council voted against moving this to the PM
so what ciaranm said is very true, people just refuse to let it become
useless
base.eclass
