On Sat, 10 Jul 2010 01:34:37 -0700 Brian Harring <ferri...@gmail.com> wrote:
> On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote:
> > The standing policy is still not to remove any public functionality from
> > eclasses. If we decide to start removing functionality the council
> > should set common rules for it.
>
> Just adding a note on this one- the original technical reason for
> this policy (portage inability to run from just the saved env dump)
> is no longer an issue.
>
> If people want to allow eclasses to have fluid APIs (specifically
> removal of functionality), that's a discussion that needs to start on
> the dev level.
>
> Anyone got strong opinions on this one?
I don't believe there ever was such a policy, except for pkg_{pre,post}rm
because of the mentioned technical limitations (which were fixed in portage
2-3 years ago now). If there is such a policy then I've violated it on
several occasions :). In fact, isn't the generally accepted method of
deprecating an eclass to remove all functionality and replace it with a
message in global scope and a "# @DEAD" tag?
I don't see the advantage of keeping unmaintained broken code no one should
use around in eclasses. You can argue that removing eclass functionality can
potentially break ebuilds in overlays, but if you follow that line of
reasoning then really we should never remove any package from the tree
because it may be a dependency of something, somewhere.
So I'd like to see a policy that treats public functions in eclasses the same
as the last rites policies for package removal: minimum 30 day deprecation
period, mail to dev-announce, etc.
--
fonts, gcc-porting, and it's all by design
toolchain, wxwidgets to keep us from losing our minds
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
