From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Kxl8K-0003WE-Ty for garchives@archives.gentoo.org; Wed, 05 Nov 2008 16:21:29 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 091B2E034C; Wed, 5 Nov 2008 16:21:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id CEA83E034C for ; Wed, 5 Nov 2008 16:21:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 1412E64206 for ; Wed, 5 Nov 2008 16:21:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 required=5.5 tests=[AWL=0.688, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1bTogUcP6j5 for ; Wed, 5 Nov 2008 16:21:20 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 63A126496F for ; Wed, 5 Nov 2008 16:21:19 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Kxl84-0001WG-2M for gentoo-dev@gentoo.org; Wed, 05 Nov 2008 16:21:12 +0000 Received: from 82.152.215.65 ([82.152.215.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Nov 2008 16:21:12 +0000 Received: from slong by 82.152.215.65 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Nov 2008 16:21:12 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: Reinstating eclasses Date: Wed, 05 Nov 2008 16:19:48 +0000 Message-ID: References: <20081104174307.5bd3d834@gentoo.org> <491097EB.4070608@gentoo.org> <20081104131525.6821d0ed@halo.dirtyepic.sk.ca> <20081104202353.43c68d49@gentoo.org> <4910A2C7.3030703@gentoo.org> 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.215.65 User-Agent: KNode/0.10.9 Sender: news X-Archives-Salt: 7410bfc6-f5e2-4bd2-a288-00a75e3f58ab X-Archives-Hash: d1cde77765d72d7762acd8901ae641c6 Duncan wrote: > Joe Peterson wrote: >> In general, it makes sense to me to have an unversioned one if there is >> no version dependency - i.e. if xfce.eclass would likely work for future >> ones (like "xfce5"). I'm not sure why, other than to emphasize that a >> new version is out, upstream packages (like gnome, kde, etc.) include >> the version in the name. I actually just think of kde as "kde", myself, >> even if it happens to be version 4. ;) > > FWIW, KDE changes major versions seldom enough and with enough > differences between versions, that it's a good time to break package > handling and get rid of the cruft at the Gentoo level as well. That's a valid reason, although eclass versioning (which someone, can't mem who, not a portage dev, told me was round the corner) would solve it more cleanly across the tree and allow the simplest name. The attraction of staying with one name is that the eclass can transition ebuilds and then lose the cruft once the packages are out of tree. Given that eclasses can test and change according to EAPI, what we have now would seem sufficient unless there is a major build system change, like KDE4 switching to cmake. > Presuming something similar for xfce, if xfce4 is taken but xfce isn't, > that would work, or perhaps xfce4ng.eclass... *ng is always good for a > round... and if it comes to it beyond that, g3, g4, etc. Of course, > that's sort of like Gentoo's -rX numbers for ebuilds, but the -rX concept > doesn't so well lend itself to the eclass concept as it implies a rather > faster turnover than we'd /hope/ to be the case, but -ng/-gX, that works. > =:^) > I like that naming schema but think it might be overkill here. Might be a more flexible way to do epochs, but I'm not sure we'd need more than one comparable value, and I think sticking to one int is sufficient.