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 1GJD0C-0001Sf-FS for garchives@archives.gentoo.org; Fri, 01 Sep 2006 17:40:24 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k81HdfgW010199; Fri, 1 Sep 2006 17:39:41 GMT Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.192.82]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k81Hbkk7012931 for ; Fri, 1 Sep 2006 17:37:47 GMT Received: from seldon (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc12) with SMTP id <20060901173745m12008dulfe>; Fri, 1 Sep 2006 17:37:45 +0000 Date: Fri, 1 Sep 2006 10:37:44 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] repoman: check for deprecated eclasses Message-ID: <20060901173744.GA5169@seldon> References: <44F84C2B.8020206@gentoo.org> <200609011857.23215.kugelfang@gentoo.org> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <200609011857.23215.kugelfang@gentoo.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: f33c4996-05fe-4d56-9367-9f42c68a3524 X-Archives-Hash: 67b82bd98dc13f13b13c1a111af9e815 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 01, 2006 at 06:57:22PM +0200, Danny van Dyk wrote: > Am Freitag, 1. September 2006 17:05 schrieb Alec Warner: > > Stefan Schweizer wrote: > > > Hi, > > > > > > Repoman needs to check for deprecated eclasses, see > > > http://bugs.gentoo.org/141677 > > > > > > As a result of the discussion in the bug, we would like to add > > > $PORTDIR/qa-data/eclass.deprecated > > > to allow to deprecate eclasses properly and make repoman fail. > > > > > > This will allow us to avoid problems with new ebuilds for > > > deprecated eclasses which result in bugs like > > > Bug 141629 dev-util/systemtap-20060325.ebuild uses deprecated > > > kernel-mod.eclass > > > I believe the developer has not known anything about that > > > kernel-mod is deprecated when making that ebuild. Now he ignores > > > the bug and we have that old eclass used again :( > > > > > > Best regards, > > > - Stefan > > > > I would prefer to see a patch for this first, and then modify > > gentoo-x86 second; but I agree in principle. What of the > > conversation about 2 files, one for "this eclass is currently being > > deprecated" -> repoman warning; and "this eclass is no longer usable" > > -> repoman failure. > > > > Also the deprecated -> new-eclass mapping. Afaik that didn't go so > > well for me; but I still like it ;) > > > > old new > > ----- ------ > > foo.eclass new-foo.eclass >=20 > We don't need a new file for that IMHO. I'd propose to add something > like >=20 > ECLASS_DEPRECATED=3D"${ECLASS_DEPRECATED} foo" > ECLASS_REPLACEMENTS=3D"${ECLASS_REPLACEMENT} new-foo" >=20 > 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,=20 this sucks; reliant on either 1) grepping it out of the file (which means there is the potential for=20 rare false positives to occur). 2) bastardizing inherit to grab it, thus forcing a sourcing for every=20 single ebuild regardless of staleness Your example above seems to indicate preferring #2, which folks will=20 probably tell you to get stuffed on, forcing a regen of the packages=20 they're examining they won't like (will slow repoman down even=20 further). Also, the new-foo renaming can't be reversed cleanly; consider if the=20 old class was kernel-mod, new class is kernels, how do you know where=20 to split old/new? You can search ECLASS_DEPRECATED, but potential for=20 collision there makes it a crappy option, in the previous example=20 consider if kernel-mode and kernel were two deprecated eclasses, it=20 would falsely label the new class as mod-kernels. Meanwhile; I'd just stick a file up somewhere on gentoo.org, and=20 mangle repoman to pull down a copy every N days as needed and have it=20 use that; code can be reused from metadata.dtd usage. ~harring --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE+G/ovdBxRoA3VU0RApDzAJ0SbDNhlLN+CmYaeBtsneE5l7TYtwCgxBYQ 4SmXom8jz39yySTDFafKCP8= =oywG -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- -- gentoo-dev@gentoo.org mailing list