[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] epatch still no helper function? [from eutils.eclass]
From:       Mike Frysinger <vapier () gentoo ! org>
Date:       2012-07-27 17:56:07
Message-ID: 201207271356.07985.vapier () gentoo ! org
[Download RAW message or body]


On Wednesday 18 July 2012 13:29:41 Ciaran McCreesh wrote:
> On Wed, 18 Jul 2012 18:18:35 +0200 "Andreas K. Huettel" wrote:
> > > On Wed, Jul 18, 2012 at 5:33 PM, hasufell <hasufell@gentoo.org>
> > > 
> > > wrote:
> > > > "epatch" is so widely used and basic that I wonder why it's still
> > > > not implemented as a real helper function.
> > > 
> > > Because then its harder to change, it must be in PMS, otherwise you
> > > have to do things like test which version of epatch the package
> > > manager provides....sounds a lot like EAPI :)
> > 
> > You know, that's actually a pretty good case *for* base.eclass,
> > eutils.eclass and similar... we should probably move more functions
> > there...  :D
> 
> I'm not sure that having to make sure you don't break ten thousand
> packages whenever you make a change is a good case... When it's EAPI
> controlled, if a change causes problems, it doesn't break anything.

and the obvious con is that it's hard to add new features and extend 
implementation details without also upgrading all EAPI aspects.  locking down 
EAPI is great for the format of the file and for simpler commands (like most of 
the install funcs), but for more complicated functions, an eclass is nicer.
-mike

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]