Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: comprehensive eclass checking in repoman
Date: Fri, 25 May 2012 16:27:50
Message-Id: 201205251228.23686.vapier@gentoo.org
In Reply to: Re: [gentoo-dev] Re: comprehensive eclass checking in repoman by Alexey Shvetsov
On Friday 25 May 2012 12:06:49 Alexey Shvetsov wrote:
> Mike Frysinger писал 2012-05-25 19:42: > > On Thursday 24 May 2012 23:47:23 Ryan Hill wrote: > >> Is there any sane way to handle sub-eclasses? eg. foo-base inherits > >> foo-functions. > > > > i was thinking of extending the metadata to handle this. did you > > have any > > specific ideas in mind ? i can see inheriting say distutils should > > not require > > people to also inherit python eclasses ... > > May we can use eclass dep graph?
no ... that sort of defeats the whole reason that drove this work. we don't want the mere fact that one eclass inherits another to imply that it's part of that eclasses guaranteed API. a lot of eclasses inherit eutils, but i don't think any of them should be guaranteeing that inherit which means ebuilds need to include it themselves if they use functions from it (like epatch). there are a cases with split up or hierarchical eclasses (java, mysql, qt, php, python, xorg come to mind) where the entry point might vary, but they all share core eclasses that largely should not be inherited by the end ebuild. maybe a new eclass-level keyword @INHERITED-API ? it takes a space delimited list of eclasses that are guaranteed by the API. so in distutils.eclass, we'd add: # @INHERITED-API: python and repoman would use this to build a tree of implicit funcs to allow w/out a direct inherit. -mike

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
[gentoo-dev] Re: comprehensive eclass checking in repoman Ryan Hill <dirtyepic@g.o>
[gentoo-dev] Re: Re: comprehensive eclass checking in repoman Steven J Long <slong@××××××××××××××××××.uk>