[gentoo-dev] base.eclass: last-rites

2021-04-09 Thread Sam James
base.eclass: last-rite eclass (mark as @DEAD)

Removal on 2021-05-09. Please port to general eclass functions/helpers.

See https://bugs.gentoo.org/497022 for information.


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] base.eclass

2012-07-09 Thread 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"
>  wrote:
> 
>> Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny:
>>> On Sun, 08 Jul 2012 19:49:25 +0200
>>> 
>>> René Neumann  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-



Re: [gentoo-dev] base.eclass

2012-07-09 Thread Alexis Ballier
On Mon, 9 Jul 2012 08:39:38 +0200
Michał Górny  wrote:

> On Sun, 8 Jul 2012 17:35:08 -0400
> Alexis Ballier  wrote:
> 
> > On Sun, 8 Jul 2012 22:10:02 +0200
> > Michał Górny  wrote:
> > 
> > > On Sun, 08 Jul 2012 19:49:25 +0200
> > > René Neumann  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

2012-07-09 Thread Ciaran McCreesh
On Mon, 09 Jul 2012 11:21:21 +0300
Samuli Suominen  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


signature.asc
Description: PGP signature


Re: [gentoo-dev] base.eclass

2012-07-09 Thread Samuli Suominen

On 07/08/2012 11:10 PM, Michał Górny wrote:

On Sun, 08 Jul 2012 19:49:25 +0200
René Neumann  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

2012-07-09 Thread Ciaran McCreesh
On Sun, 8 Jul 2012 23:40:29 +0200
"Andreas K. Huettel"  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


signature.asc
Description: PGP signature


Re: [gentoo-dev] base.eclass

2012-07-08 Thread Michał Górny
On Sun, 8 Jul 2012 23:40:29 +0200
"Andreas K. Huettel"  wrote:

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


signature.asc
Description: PGP signature


Re: [gentoo-dev] base.eclass

2012-07-08 Thread Michał Górny
On Sun, 8 Jul 2012 17:35:08 -0400
Alexis Ballier  wrote:

> On Sun, 8 Jul 2012 22:10:02 +0200
> Michał Górny  wrote:
> 
> > On Sun, 08 Jul 2012 19:49:25 +0200
> > René Neumann  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


signature.asc
Description: PGP signature


Re: [gentoo-dev] base.eclass

2012-07-08 Thread Andreas K. Huettel
Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny:
> On Sun, 08 Jul 2012 19:49:25 +0200
> 
> René Neumann  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 
dilfri...@gentoo.org
http://www.akhuettel.de/



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] base.eclass

2012-07-08 Thread Alexis Ballier
On Sun, 8 Jul 2012 22:10:02 +0200
Michał Górny  wrote:

> On Sun, 08 Jul 2012 19:49:25 +0200
> René Neumann  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

2012-07-08 Thread Pacho Ramos
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  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


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] base.eclass

2012-07-08 Thread René Neumann
Am 08.07.2012 22:10, schrieb Michał Górny:
> On Sun, 08 Jul 2012 19:49:25 +0200
> René Neumann  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é



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] base.eclass

2012-07-08 Thread Michał Górny
On Sun, 08 Jul 2012 19:49:25 +0200
René Neumann  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


signature.asc
Description: PGP signature


Re: [gentoo-dev] base.eclass

2012-07-08 Thread Mike Gilbert
On Sun, Jul 8, 2012 at 1:54 PM, Ciaran McCreesh
 wrote:
> On Sun, 08 Jul 2012 19:49:25 +0200
> René Neumann  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

2012-07-08 Thread Ciaran McCreesh
On Sun, 08 Jul 2012 19:49:25 +0200
René Neumann  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


signature.asc
Description: PGP signature


[gentoo-dev] base.eclass

2012-07-08 Thread René Neumann
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é



signature.asc
Description: OpenPGP digital signature