From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OXogn-0000tw-80 for garchives@archives.gentoo.org; Sun, 11 Jul 2010 05:02:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BFACEE0AB0; Sun, 11 Jul 2010 05:02:49 +0000 (UTC) Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 4A239E0A92 for ; Sun, 11 Jul 2010 05:02:29 +0000 (UTC) Received: by vws15 with SMTP id 15so3579851vws.40 for ; Sat, 10 Jul 2010 22:02:28 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.220.49.202 with SMTP id w10mr5966588vcf.210.1278824548554; Sat, 10 Jul 2010 22:02:28 -0700 (PDT) Sender: cardoe@cardoe.com Received: by 10.220.182.77 with HTTP; Sat, 10 Jul 2010 22:02:28 -0700 (PDT) In-Reply-To: <20100710210258.2005f27c@gentoo.org> References: <4C37A114.9070604@gentoo.org> <4C381392.5050505@gentoo.org> <20100710083437.GA6598@hrair> <20100710210258.2005f27c@gentoo.org> Date: Sun, 11 Jul 2010 00:02:28 -0500 X-Google-Sender-Auth: Bds443YMBZJuRnQSAiEgEPtXNvE Message-ID: Subject: Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others From: Doug Goldstein To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e2be4556-527b-435f-a9c4-44c9abbbee9c X-Archives-Hash: a3e16beba4f625081cd88707f8c1564f On Sat, Jul 10, 2010 at 10:02 PM, Ryan Hill wrote: > On Sat, 10 Jul 2010 01:34:37 -0700 > Brian Harring 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 fr= om >> > 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 porta= ge > 2-3 years ago now). =C2=A0If there is such a policy then I've violated it= on > several occasions :). =C2=A0In 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 shou= ld > use around in eclasses. =C2=A0You can argue that removing eclass function= ality 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: =C2=A0minimum 30 day depr= ecation > period, mail to dev-announce, etc. > > > -- > fonts, gcc-porting, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and it's= all by design > toolchain, wxwidgets =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to keep us from losing our minds > @ gentoo.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0EFFD = 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? --=20 Doug Goldstein