From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GJM12-0002i5-Hh for garchives@archives.gentoo.org; Sat, 02 Sep 2006 03:17:52 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k823HBpc019114; Sat, 2 Sep 2006 03:17:11 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k823ESAB001996 for ; Sat, 2 Sep 2006 03:14:30 GMT Received: from phi.witten.lan (p83.129.30.193.tisdip.tiscali.de [83.129.30.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id E45F364836 for ; Fri, 1 Sep 2006 23:25:59 +0000 (UTC) From: Danny van Dyk Organization: Gentoo To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] repoman: check for deprecated eclasses Date: Sat, 2 Sep 2006 01:37:26 +0200 User-Agent: KMail/1.9.3 References: <200609011857.23215.kugelfang@gentoo.org> <20060901173744.GA5169@seldon> In-Reply-To: <20060901173744.GA5169@seldon> X-Face: =?utf-8?q?57Z3foFdBj=3BKdmU=5EFM=2Eec=5C4=7BQf/F6=25ePh=5C=5DM=5EaXPX*=5D?= =?utf-8?q?J5S=7CM=7E+vR=3F=24iW=5Cn44=5E2sguPTOtw=0A=09fe+7gKTm*!OXGQPYqML?= =?utf-8?q?=7CL1ezSI3-=27E=25zxZigvAK?=>3$?~'4IPBoi\H2)pV6U(26V@ =?utf-8?q?jq=7CAIp=0A=09yY?=>'!D}EOi=Q+-|CIh-d4riWfZZ">G.Rj!}78kX$8Zt0:epNWTo[{_/zJb< =?utf-8?q?Ud=2Eon=7EprEW*=0A=09tIvqI=7B+e=3AgMC?= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609020137.26939.kugelfang@gentoo.org> X-Archives-Salt: 961a3ec2-cc74-45e6-bbf9-d24499faadde X-Archives-Hash: 274f443643eb8d18ca42793292a589f4 Am Freitag, 1. September 2006 19:37 schrieb Brian Harring: > > > > > > old new > > > ----- ------ > > > foo.eclass new-foo.eclass > > > > We don't need a new file for that IMHO. I'd propose to add > > something like > > > > ECLASS_DEPRECATED="${ECLASS_DEPRECATED} foo" > > ECLASS_REPLACEMENTS="${ECLASS_REPLACEMENT} new-foo" > > > > to foo.eclass. In my eyes this is much less work as repoman merely > > has to check for 2 envvars. > > As much as I'm a fan of embedding the metadata into the object > itself, this sucks; reliant on either > > 1) grepping it out of the file (which means there is the potential > for rare false positives to occur). Correct, i don't like to grep for it. > > 2) bastardizing inherit to grab it, thus forcing a sourcing for every > single ebuild regardless of staleness Exactly. > Your example above seems to indicate preferring #2, which folks will > probably tell you to get stuffed on, forcing a regen of the packages > they're examining they won't like (will slow repoman down even > further). Well, one has to decide between functionality and speed at times. I think it's better to have the ebuild sourced on every run instead of sourcing it only when it cache is stale. > Also, the new-foo renaming can't be reversed cleanly; consider if the > old class was kernel-mod, new class is kernels, how do you know where > to split old/new? You can search ECLASS_DEPRECATED, but potential > for collision there makes it a crappy option, in the previous example > consider if kernel-mode and kernel were two deprecated eclasses, it > would falsely label the new class as mod-kernels. ECLASS_DEPRECATED="${ECLASS_DEPRECATED} foo:new-foo,new-foo-modules" > Meanwhile; I'd just stick a file up somewhere on gentoo.org, and > mangle repoman to pull down a copy every N days as needed and have it > use that; code can be reused from metadata.dtd usage. I like this option better than sticking another file into the public tree that no user will ever need. Danny -- Danny van Dyk Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list