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 1GJOYS-00029Z-66 for garchives@archives.gentoo.org; Sat, 02 Sep 2006 06:00:32 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k825x7wu022929; Sat, 2 Sep 2006 05:59:07 GMT Received: from alnrmhc12.comcast.net (alnrmhc12.comcast.net [206.18.177.52]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k825v7AV022201 for ; Sat, 2 Sep 2006 05:57:08 GMT Received: from seldon (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (alnrmhc12) with SMTP id <20060902055706b120058ti5e>; Sat, 2 Sep 2006 05:57:06 +0000 Date: Fri, 1 Sep 2006 22:57:05 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] repoman: check for deprecated eclasses Message-ID: <20060902055705.GB12098@seldon> References: <200609011857.23215.kugelfang@gentoo.org> <20060901173744.GA5169@seldon> <200609020137.26939.kugelfang@gentoo.org> <20060902035118.GA12098@seldon> <1157172817.6775.1.camel@Leo> 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="NMuMz9nt05w80d4+" Content-Disposition: inline In-Reply-To: <1157172817.6775.1.camel@Leo> User-Agent: Mutt/1.5.11 X-Archives-Salt: ff290b35-5341-4d0f-832e-731c0e9f5290 X-Archives-Hash: 754a563d231e4bdf197f4bc4d8ddf1b8 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 01, 2006 at 09:54:09PM -0700, Daniel Ostrow wrote: > >=20 > > > I like this option better than sticking another file into the public= =20 > > > tree that no user will ever need. > >=20 > > Instead, modifying the eclass metadata and adding two new keys, that=20 > > users will never need is fine? :) > >=20 > > This isn't really user data, tiz developer data; thus the user bit=20 > > doesn't matter. Sarcasm aside, what *does* matter as that the=20 > > purpose of this is a temporary hack to cover portages ass. > >=20 > In light of it being useless data for users is there any reason not to > add the files to CVS and then pull them out before the tree is synced > with the master mirror as part of that script? Devs are lazy and don't always do a full cvs up, same reason the=20 repoman metadata.xml check relies on pulling metadata.dtd down,=20 instead of having a copy pushed into the cvs repository. Re: yoinking the file from the cvs->rsync transfer, frankly who cares. =20 It's one file out of 124 _thousand_ files; <400 bytes. Really ain't=20 worth it. ~brian --NMuMz9nt05w80d4+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE+R0xvdBxRoA3VU0RAo3zAKDnuohe7ZcnAecx5l8/gU3AUFBzBwCePD9e LxG8mCB3mjj/U6QwzDmUMyQ= =HjT9 -----END PGP SIGNATURE----- --NMuMz9nt05w80d4+-- -- gentoo-dev@gentoo.org mailing list