Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Doug Goldstein <cardoe@gentoo.org>]

On Sat, Jul 10, 2010 at 10:02 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Sat, 10 Jul 2010 01:34:37 -0700
> Brian Harring <ferringb@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
>

To be honest, the MythTV eclasses have been an ever evolving set of
eclasses for ages now. Ever since it was declared that its now safe to
remove eclasses from the tree since Portage saves eclasses and its
env, therefore it wouldn't cause a problem.

If I really need to go to the council with every change, considering
it must be debated on the ML for at least X number of days prior to
going to the council, I'd more likely just remove MythTV from the tree
and maintain it in an overlay. I don't invest a lot of time in the
MythTV ebuilds, but they work for a large majority of people. And when
a new version comes out it requires some retooling and it just works
for everyone.

So basically, you guys decide.. am I pulling them out of the tree or
am I leaving them in?

-- 
Doug Goldstein