[gentoo-dev] base.eclass

[gentoo-dev] base.eclass

[René Neumann]

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

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?

In my special case, I discovered that I cannot rely on 'PATCHES' being
honored and hence have to introduce something like:

src_prepare () {
   epatch "some.patch"
   distutils_src_prepare
}

And, imho, this is just noise -- having PATCHES=( "some.patch" ) would
be clearer :)

Thanks,
René


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] base.eclass

[Ciaran McCreesh]

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

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...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] base.eclass

[Mike Gilbert]

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.

Re: [gentoo-dev] base.eclass

[Michał Górny]

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

On Sun, 08 Jul 2012 19:49:25 +0200
René Neumann <lists@necoro.eu> wrote:

> 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].

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] base.eclass

[René Neumann]

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

Am 08.07.2012 22:10, schrieb Michał Górny:
> On Sun, 08 Jul 2012 19:49:25 +0200
> René Neumann <lists@necoro.eu> wrote:
> 
>> 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.)

- René


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] base.eclass

[Pacho Ramos]

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

El dom, 08-07-2012 a las 22:59 +0200, René Neumann escribió:
> Am 08.07.2012 22:10, schrieb Michał Górny:
> > On Sun, 08 Jul 2012 19:49:25 +0200
> > René Neumann <lists@necoro.eu> wrote:
> > 
> >> 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.)
> 
> - René
> 

And, if we are supposed to stop using it, it should print some kind of
warning to remember developers to drop its usage

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] base.eclass

[Alexis Ballier]

On Sun, 8 Jul 2012 22:10:02 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 08 Jul 2012 19:49:25 +0200
> René Neumann <lists@necoro.eu> wrote:
> 
> > 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].
> 

what is the PATCHES=() replacement in new eapis? (mainly why i use
base.eclass more and more these days)

Re: [gentoo-dev] base.eclass

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1030 bytes --]

Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny:
> On Sun, 08 Jul 2012 19:49:25 +0200
> 
> René Neumann <lists@necoro.eu> wrote:
> > 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].

Please clarify this. 

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/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] base.eclass

[Michał Górny]

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

On Sun, 8 Jul 2012 17:35:08 -0400
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 8 Jul 2012 22:10:02 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Sun, 08 Jul 2012 19:49:25 +0200
> > René Neumann <lists@necoro.eu> wrote:
> > 
> > > 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].
> > 
> 
> what is the PATCHES=() replacement in new eapis? (mainly why i use
> base.eclass more and more these days)

That's what I used:

[[ ${PATCHES} ]] && epatch "${PATCHES[@]}"

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] base.eclass

[Michał Górny]

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

On Sun, 8 Jul 2012 23:40:29 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny:
> > On Sun, 08 Jul 2012 19:49:25 +0200
> > 
> > René Neumann <lists@necoro.eu> wrote:
> > > 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].
> 
> Please clarify this. 
> 
> 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.

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

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

Re: [gentoo-dev] base.eclass

[Ciaran McCreesh]

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

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.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] base.eclass

[Samuli Suominen]

On 07/08/2012 11:10 PM, Michał Górny wrote:
> On Sun, 08 Jul 2012 19:49:25 +0200
> René Neumann <lists@necoro.eu> wrote:
>
>> 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].
>

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

Re: [gentoo-dev] base.eclass

[Ciaran McCreesh]

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

On Mon, 09 Jul 2012 11:21:21 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> 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

Perhaps you should view the Council's vote as advice that passing
arguments that way is unpopular and unlikely to endear you to your
fellow developers.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] base.eclass

[Alexis Ballier]

On Mon, 9 Jul 2012 08:39:38 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 8 Jul 2012 17:35:08 -0400
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Sun, 8 Jul 2012 22:10:02 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > On Sun, 08 Jul 2012 19:49:25 +0200
> > > René Neumann <lists@necoro.eu> wrote:
> > > 
> > > > 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].
> > > 
> > 
> > what is the PATCHES=() replacement in new eapis? (mainly why i use
> > base.eclass more and more these days)
> 
> That's what I used:
> 
> [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
> 


and ? thanks, I can read the code :)
are you suggesting people to duplicate the code ? this is in no way a
replacement...

A.

Re: [gentoo-dev] base.eclass

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/09/2012 08:45 AM, Michał Górny wrote:
> On Sun, 8 Jul 2012 23:40:29 +0200 "Andreas K. Huettel"
> <dilfridge@gentoo.org> wrote:
> 
>> Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny:
>>> On Sun, 08 Jul 2012 19:49:25 +0200
>>> 
>>> René Neumann <lists@necoro.eu> wrote:
>>>> 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].
>> 
>> Please clarify this.
>> 
>> 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.
> 
> 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).
> 

There are tons of eclasses "randomly" exporting phase functions. That
is not the problem. The problem is that other eclasses inherit
base.eclass. Only that leads to this mess.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP+tmXAAoJEFpvPKfnPDWz2JMH/AwYoHvD9vIBhSSDCQ6np/L5
NzDHuKcqUKKQ5bs9+gHWSf81lFaazu9mw187d1o016nD6TQ1rPjbulQhU9ZLuCt1
qDGBAH1j1vPOktstxzkAXWRzkmbkGir9hz5Mw8WO+AXvcHa5sP4stiaNQyL6ZKhe
hhfLkZC+ToZP8CcW7yeS8nC910bvDV9hVfNxsBOMR/EKY/aSnHcsfOf4c3pCX9xd
YrrEvoT9zdx9827sk8+PO4m4kAZsvjem7IiTTa+LRH1wPf5DBpjL19c0pSyHF3Kc
kBDL4BFrT4lqoNhO0vDXL45AVRsKz2/G0Tu7XLg2ewwCZByPpPlGR277wLjRo44=
=DaE5
-----END PGP SIGNATURE-----