[gentoo-dev] How shall we name the EAPI 6 patch applying function?

[gentoo-dev] How shall we name the EAPI 6 patch applying function?

[Michał Górny]

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

Hello all,

Wrt bug #463692 [1] we'd like to add a default src_prepare() in EAPI 6,
with PATCHES array and user patches support. For that reason, I've
requested in bug #463768 [2], that the function used to apply
the patches would be public -- so that users and eclasses could use it
consequently.

After some discussion on the relevant bug we came to the conclusion
that the epatch function is relentlessly bloated. It provides a lot
of features which are either already discouraged by its maintainer
(arch-prefixed patches), result in widespread QA issues (compressed
patch support) or is just too hard to implement reasonably.

For that reason, the new function will most likely support
the following:

a) patch files can be specified directly or through a directory
   in which *all* files will be applied in lexical order,

b) patches will be applied with -p1 unless overrode via direct
   arguments to patch applying function.

Rationale will follow. Since that functionality is very limited
compared to the epatch function, we will keep the old one in the eclass
for anyone really needing it. However, we need a name for the new
function.

Therefore, I ask you: how should we name the new (and simpler) patch
applying function which will be provided in EAPI 6?

[1]:https://bugs.gentoo.org/show_bug.cgi?id=463692
[2]:https://bugs.gentoo.org/show_bug.cgi?id=463768


Please note that the following rationale is assembled mostly from my
opinion and understanding of the others. Please do not take is
as an official Gentoo statement.

Short rationale:

1) automatic -p* support has seen most effort to keep in the spec.
However, there are a few important issues with it which outweigh
the usefulness of it:

* inability to know what intended patchlevel was can result in patches
  being applied to wrong files (e.g. when patch stops to apply
  to the intended file or start to apply to an unintended file with
  a lower patchlevel).

* the patches stored in the tree can't be easily reused upstream
  or by users since 'epatch' is limited to ebuild scope.

* the current implementation of epatch results in hard-to-read error
  output (you have to grep for the 'most proper' run).

This also implies that due to a new QA policy, Gentoo tree will consist
only of patches adjusted to be used with '-p1'. If nobody steps up
earlier, I will write a tool to fix patches to proper patchlevel.


2) compressed patch support is likely the most misused feature
in epatch. This is because in the most cases it was used:

* (in Sunrise overlay) to apply compressed patches from ${FILESDIR} --
  where storing compressed files there is a violation of QA policy.

* to apply compressed patches from ${DISTDIR} -- when src_unpack()
  has uncompressed the patches to ${WORKDIR} already.

Considering that the most compressed patches will either be downloaded
as compressed files or compressed archives, the responsibility for
unpacking them will fall on src_unpack(). Therefore, we believe that
there's no need for additional layer of complexity here.


3) support for directories was one of the most obfuscated features
of epatch. It included a number of adjustment variables like
EPATCH_SUFFIX, EPATCH_FORCE (where nobody could guess its meaning),
EPATCH_EXCLUDE and the discouraged arch-prefixed patches.

I've taken a quick grep of the Gentoo ebuild tree and the Gentoo patch
tree, and it seems that:

* only sys-libs/glibc seems to be still using arch-conditional patching.

* most of the patch directories consist of files prefixed by ordering
  number, suffixed by either '.patch' or '.diff'.

* some of the patch trees use Debian-style patches. That is, randomly
  named files with 'series' file determining the order of applying.

We've chosen the common solution which will work correctly for most
of the ebuilds with no need for additional control variables. Other
cases will either need to use globs to choose files directly,
or the eclass-defined epatch function.


I hope I covered all the main points. If I missed something, please let
me know.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[Michał Górny]

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

There was a slight mis-understanding between me and ulm.

On Wed, 3 Apr 2013 11:14:37 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> a) patch files can be specified directly or through a directory
>    in which *all* files will be applied in lexical order,

Correction: files which match '*.patch' and '*.diff'. This avoids
catching 'README' files, 'series' files and any reasonable kind
of backup files.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[hasufell]

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

You also have to rename the PATCHES array, because base.eclass already
uses that name with epatch.

And I can't say I am thrilled about the idea that we duplicate
functionality again. It's already confusing enough the way it is (I
can tell, because I review ebuilds in sunrise regularly. What might
look trivial to us, is confusing for regular contributors). We should
put more effort into providing centralized functions and deprecate old
stuff.
But I have a feeling that providing a second patch function with
reduced functionality will not help with that.

I don't think it's too bad to include the automatic -p# detection,
because it can be overridden anyway. The cases where you really need
to do that are rare enough to leave detection as default.

Also I don't think it's too bad to drop some functionality and still
not rename the function, so that we have slightly different epatch
behavior in EAPI=6. That can be communicated and old ebuilds will
still use eutils epatch for older EAPIs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRXCGaAAoJEFpvPKfnPDWzDWMIAI3aU5w+FGEtWTfkQ5FkldDp
1UJhseirhYxQqRykZJoKdWCSRPqQbUCThbkLoiHvPsvsSr4Os6lR3Ycyfzs0U5di
ZxNfuL3ykyB42mbkh+YpHwAFr6B6FdPxVoz0XKlpKVM5LDgUDqHmNrd+s3v8/n/D
XYGOf95DCtOnZbiINfn5jvf63L9R9Cp95cFqbv0xphVt5yIjD3f9xJsXWfclwcuS
6S3FrIpMF94x6howB/Z4ifQrh9oWy4ivB6mGlOcadTDzhBZkY2/aM25nLg3zW0h7
nSd8KASR3wVYYwWKntyUxoWdkQ49JbkC+WAv1X9VingpA8NPkvtqfx54WDtTc3I=
=zKvF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[William Hubbs]

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

On Wed, Apr 03, 2013 at 11:56:09AM +0200, Michał Górny wrote:
> There was a slight mis-understanding between me and ulm.
> 
> On Wed, 3 Apr 2013 11:14:37 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > a) patch files can be specified directly or through a directory
> >    in which *all* files will be applied in lexical order,
> 
> Correction: files which match '*.patch' and '*.diff'. This avoids
> catching 'README' files, 'series' files and any reasonable kind
> of backup files.

I like src_patch.

William


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

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[Ciaran McCreesh]

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

On Wed, 03 Apr 2013 14:33:30 +0200
hasufell <hasufell@gentoo.org> wrote:
> You also have to rename the PATCHES array, because base.eclass already
> uses that name with epatch.

base.eclass should have died a horrible death a long time ago. A new
EAPI is an excellent opportunity to ban it.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlFcSu4ACgkQ96zL6DUtXhEXTQCgjcw7R3u8xXcsFWiLd85BxAbN
W04AnjlclAx3xLpbXot8TwDmdZxsV3s/
=wiQJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[Michał Górny]

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

On Wed, 3 Apr 2013 11:14:37 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Therefore, I ask you: how should we name the new (and simpler) patch
> applying function which will be provided in EAPI 6?

My propositions:

- apply_patches ...
- apply_user_patches

Where I think we used the latter name when discussing adding user patch
support.


-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[Tomáš Chvátal]

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

Dne St 3. dubna 2013 16:29:48, Ciaran McCreesh napsal(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 03 Apr 2013 14:33:30 +0200
> hasufell <hasufell@gentoo.org> wrote:
> 
> > You also have to rename the PATCHES array, because base.eclass already
> > uses that name with epatch.
> 
> 
> base.eclass should have died a horrible death a long time ago. A new
> EAPI is an excellent opportunity to ban it.
> 

This is actually good idea to ban the base.eclass usage, but wonder how 
complex it would make all the eclasses that currently inherit it.

Tom

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

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[Ciaran McCreesh]

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

On Wed, 03 Apr 2013 19:06:31 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 04/03/2013 05:29 PM, Ciaran McCreesh wrote:
> > On Wed, 03 Apr 2013 14:33:30 +0200 hasufell <hasufell@gentoo.org>
> > wrote:
> >> You also have to rename the PATCHES array, because base.eclass
> >> already uses that name with epatch.
> > 
> > base.eclass should have died a horrible death a long time ago. A
> > new EAPI is an excellent opportunity to ban it.
> > 
> 
> That is not possible without the agreement of the eclass maintainers.
> So you cannot just "ban" an eclass.

QA certainly can, and should. Or failing that, the Council can step in.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlFcYVIACgkQ96zL6DUtXhG7nwCcCLClcG0etUSBuFAupj1nmJMw
iQIAoKxQMWsqEKwp7NRTUqAPbQNIeXFk
=33rM
-----END PGP SIGNATURE-----

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[hasufell]

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

On 04/03/2013 05:29 PM, Ciaran McCreesh wrote:
> On Wed, 03 Apr 2013 14:33:30 +0200 hasufell <hasufell@gentoo.org>
> wrote:
>> You also have to rename the PATCHES array, because base.eclass
>> already uses that name with epatch.
> 
> base.eclass should have died a horrible death a long time ago. A
> new EAPI is an excellent opportunity to ban it.
> 

That is not possible without the agreement of the eclass maintainers.
So you cannot just "ban" an eclass.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRXGGXAAoJEFpvPKfnPDWz7DMH/0crt8ANEKsqp6WsB4mAs7Vr
7g7Q+nGdvsXyfXVaU9o65S7hFANElXUsYYt5pyOliO2bQVKyGxIxKDO5WPdcJfVO
rEwEtCLAJrrknMa8TlHol7tAkcXCCCFlM0OZYvGJFJPaaOTwq7bRhdqEN2xoGOJy
xW+aDLuhmS38dxGHiRP8s3BsD/8vuNDDCETOKfbid9SSjoB3HlhzM/4Um5bzsu+y
XwUQLU+VndcSqa45PHYl8ai9JFxRDmwNSutA7jkzJ2ogksJ1rbZ5bzIUyTxnpyqu
2qbfcEjD0UQ9OF80p14OJzJdxOzYu9p0ATH37iVXgSvYQdGOle0Y2IUctYd60p0=
=MnS5
-----END PGP SIGNATURE-----

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[Michał Górny]

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

On Wed, 03 Apr 2013 18:56:29 +0200
Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:

> Dne St 3. dubna 2013 16:29:48, Ciaran McCreesh napsal(a):
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Wed, 03 Apr 2013 14:33:30 +0200
> > hasufell <hasufell@gentoo.org> wrote:
> > 
> > > You also have to rename the PATCHES array, because base.eclass already
> > > uses that name with epatch.
> > 
> > 
> > base.eclass should have died a horrible death a long time ago. A new
> > EAPI is an excellent opportunity to ban it.
> > 
> 
> This is actually good idea to ban the base.eclass usage, but wonder how 
> complex it would make all the eclasses that currently inherit it.

I think EAPI 6 should export all the means necessary to reimplement
the missing parts of it, inclusing user docs install and patch
application functions. Is there anything else that would be necessary?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] How shall we name the EAPI 6 patch applying function?

[Rich Freeman]

On Wed, Apr 3, 2013 at 1:05 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Wed, 03 Apr 2013 19:06:31 +0200
> hasufell <hasufell@gentoo.org> wrote:
>> That is not possible without the agreement of the eclass maintainers.
>> So you cannot just "ban" an eclass.
>
> QA certainly can, and should. Or failing that, the Council can step in.
>

No need to have a fight.

If there are reasons not to move everything into the EAPI they should
be discussed.  It takes months to implement a new EAPI in general so
the eclass maintainers will be involved I'm sure and everybody can
coordinate nicely.

And the Council already approves all EAPIs, so if for whatever reason
there is a need to make a call they can do so.

There is no need to argue about hypothetical domains of authority.
Let's instead focus on what is the best way to move forward, hope for
consensus, and then deal with disagreement only when that time comes.

Rich

[gentoo-dev] Re: How shall we name the EAPI 6 patch applying function?

[Ryan Hill]

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

On Wed, 3 Apr 2013 18:36:07 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Wed, 3 Apr 2013 11:14:37 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Therefore, I ask you: how should we name the new (and simpler) patch
> > applying function which will be provided in EAPI 6?
> 
> My propositions:
> 
> - apply_patches ...
> - apply_user_patches
> 
> Where I think we used the latter name when discussing adding user patch
> support.

blech too long, underscores.  how about dopatch?

if at all possible, please keep EPATCH_EXCLUDE around.  it's just too damned
useful.


-- 
gcc-porting
toolchain, wxwidgets
@ gentoo.org

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