[gentoo-dev] base.eclass: last-rites
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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