public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alexis Ballier <aballier@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review
Date: Sun, 18 Oct 2015 11:34:15 +0200	[thread overview]
Message-ID: <20151018113415.4901ff3e@gentoo.org> (raw)
In-Reply-To: <20151018110127.1f311870.mgorny@gentoo.org>

On Sun, 18 Oct 2015 11:01:27 +0200
Michał Górny <mgorny@gentoo.org> wrote:
[...]
> > > It's trivial to change patch to -p1 (I think patchutils can do
> > > that).    
> > 
> > It is. But the above cases were not whether it is possible, but
> > rather desirable.  
> 
> Consistency is desirable. There is world outside ebuilds, and they
> need to apply patches sometimes.

Yes, that's why I find '-p1 relative to $S' inconsistent. Nothing wrong
with -p1, but $S is from ebuild. If you avoid '$S', then you must also
drop -p1, simple as that :)

> > > It's beneficial to keep patches with predictable directory
> > > structure. And after all, you can use 'eapply -pN' explicitly.
> > > And yes, I know you hate having to think instead of having some
> > > random hidden implicit, likely-to-fail logic do it for you.    
> > 
> > Well, there's that, but I also wonder why every single ebuild uses
> > epatch and not 'patch -p1 < ...'  directly if epatch is so bad...  
> 
> Because 'patch -p1 < ... || die' needs to be repeated multiple times
> for each file. Simple as that.

Honestly, I have serious doubts that's the only reason :=)

> > But my point was not there: I still fail to understand why we should
> > set in stone something not so well tested in comparison to epatch,
> > that doesn't seem to provide any gain besides a default phase that
> > an eclass can also provide, that has less features and that can't be
> > changed/fixed easily.  
> 
> epatch is not well tested. Some of its branches are. Some of its code
> was changed due to failures. We're reusing the parts of epatch that
> make sense.
> 
> Otherwise, epatch would take more space in PMS than all stuff about
> ebuilds added together, would require change in EAPI every 6 months,
> plus a number of bugfix releases due to broken implementations of
> over-complex concept.


I don't claim that epatch should go to PMS nor that eapply is bad: I
actually agree that for PMS something like eapply is way much better
than epatch.
What I do claim, however, is that PMS is not the place to throw random
widely used functions that can very well be defined in eclasses and
improved without going through all the PMS paperwork (which paperwork
is good for its purpose, but like for multilib, should be avoided when
possible).

Alexis.


  reply	other threads:[~2015-10-18  9:34 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <22049.17676.1822.986579@a1i15.kph.uni-mainz.de>
2015-10-17 12:19 ` [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review Jason A. Donenfeld
2015-10-17 12:21   ` Jason A. Donenfeld
2015-10-17 12:24   ` Michał Górny
2015-10-17 12:28     ` hasufell
2015-10-17 12:52       ` Ulrich Mueller
2015-10-17 12:56         ` hasufell
2015-10-17 13:07           ` Ulrich Mueller
2015-10-17 15:22             ` hasufell
2015-10-17 16:40               ` Alexis Ballier
2015-10-17 22:16         ` Rich Freeman
2015-10-18  8:33           ` Alexis Ballier
2015-10-18  9:54           ` Ulrich Mueller
2015-10-18  9:56             ` Alexis Ballier
2015-10-18 10:13             ` Michał Górny
2015-10-18 10:17               ` Ulrich Mueller
2015-10-18 10:49                 ` Rich Freeman
2015-10-19  7:12                 ` Alexis Ballier
2015-10-19  7:22                   ` Anthony G. Basile
2015-10-19  7:28                     ` Alexis Ballier
2015-10-19  8:25                     ` Ulrich Mueller
2015-10-19  8:31                       ` Alexis Ballier
2015-10-19  7:58                   ` Michał Górny
2015-10-19  8:04                     ` Alexis Ballier
2015-10-19  8:09                       ` Michał Górny
2015-10-19  8:17                         ` Alexis Ballier
2015-10-19  8:07                     ` Anthony G. Basile
2015-10-19 22:07                     ` Andreas K. Huettel
2015-10-19 12:38                   ` Rich Freeman
2015-10-19 13:34                     ` Alexis Ballier
2015-10-19 13:51                       ` Rich Freeman
2015-10-19 14:21                         ` Alexis Ballier
2015-10-19 17:17                           ` Rich Freeman
2015-10-19 18:28                             ` Alexis Ballier
2015-10-19 19:49                               ` Rich Freeman
2015-10-20  7:51                                 ` Alexis Ballier
2015-10-20  8:57                                   ` Rich Freeman
2015-10-20  9:22                                     ` Alexis Ballier
2015-10-20 10:00                                       ` Rich Freeman
2015-10-20 10:25                                         ` Alexis Ballier
2015-10-21  1:24                                           ` Duncan
2015-10-21  7:29                                             ` Alexis Ballier
2015-10-18 10:36             ` Alexis Ballier
2015-10-20  7:47         ` Daniel Campbell
2015-10-20  8:00           ` Alexis Ballier
2015-10-17 12:42     ` Ulrich Mueller
2015-10-17 12:25   ` hasufell
2015-10-17 12:38     ` Rich Freeman
2015-10-17 12:49       ` hasufell
2015-10-17 12:56         ` Rich Freeman
2015-10-17 13:02           ` hasufell
2015-10-17 13:47         ` Alexis Ballier
2015-10-17 15:00           ` hasufell
2015-10-17 16:07             ` Anthony G. Basile
2015-10-17 16:35               ` Alexis Ballier
2015-10-17 18:03         ` Ciaran McCreesh
2015-10-18 11:37           ` hasufell
2015-10-18 11:43             ` Rich Freeman
2015-10-18 12:05               ` hasufell
2015-10-18 12:24                 ` Rich Freeman
2015-10-17 12:51       ` Michał Górny
2015-10-17 19:15         ` Rich Freeman
2015-10-17 20:08 ` Alexis Ballier
2015-10-17 20:47   ` Ulrich Mueller
2015-10-18  8:31     ` Alexis Ballier
2015-10-18  8:48       ` Michał Górny
2015-10-18  9:23         ` Alexis Ballier
2015-10-18 10:07           ` Michał Górny
2015-10-18 10:34             ` Alexis Ballier
2015-10-18 11:54           ` Andreas K. Huettel
2015-10-18 11:57             ` Alexis Ballier
2015-10-18 12:44       ` Ciaran McCreesh
2015-10-18 13:01         ` Rich Freeman
2015-10-18 18:00         ` Alexis Ballier
2015-10-18 18:06           ` Ciaran McCreesh
2015-10-18 18:19             ` Alexis Ballier
2015-10-18 18:36               ` Ciaran McCreesh
2015-10-18 19:20                 ` Alexis Ballier
2015-10-17 21:24   ` Michał Górny
2015-10-18  8:47     ` Alexis Ballier
2015-10-18  9:01       ` Michał Górny
2015-10-18  9:34         ` Alexis Ballier [this message]
2015-10-18 10:09           ` Michał Górny
2015-10-18 10:31             ` Alexis Ballier
2015-10-20 18:55 ` [gentoo-dev] utilizing BASH_COMPAT to smooth upgrades Mike Frysinger
2015-10-20 22:03   ` Ulrich Mueller
2015-10-20 22:51     ` Mike Frysinger
2015-10-21  7:34       ` [gentoo-dev] [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades) Ulrich Mueller
2015-10-22 13:55         ` [gentoo-dev] " Mike Frysinger
2015-10-22 15:00           ` Ulrich Mueller
2015-10-22 15:21             ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151018113415.4901ff3e@gentoo.org \
    --to=aballier@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox