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 <gentoo-dev+bounces-38003-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Mw15Z-0001qD-JH
for garchives@archives.gentoo.org; Thu, 08 Oct 2009 22:03:57 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 265BFE0A96;
Thu, 8 Oct 2009 22:03:56 +0000 (UTC)
Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211])
by pigeon.gentoo.org (Postfix) with ESMTP id D006EE0A96
for <gentoo-dev@lists.gentoo.org>; Thu, 8 Oct 2009 22:03:55 +0000 (UTC)
Received: by bwz7 with SMTP id 7so1516725bwz.34
for <gentoo-dev@lists.gentoo.org>; Thu, 08 Oct 2009 15:03:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:sender:received:in-reply-to
:references:date:x-google-sender-auth:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=PdhWlBkCVr7+GF8gcv1ed3MXNNNcS1Mc9c19iaPiZ8U=;
b=c1TYjzeNvTjEXfPB/nJS9U6K46v932xd30v2pFT9TMEnJ4P9en8/upO1CXgE0jWB4a
wLvaRrJ7gEOgW3i1VN3AAirqnEOXGvnGSbGlDl+NJkPaR1Yuo+dpUwLGSUP2HTstTP7j
QrUt3ADsGxZbssFa5N14hGoOwlYW1oxe6iwV4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type
:content-transfer-encoding;
b=SQOXNX4iqfWpJZOj2P8qFCogen7hlh7qUx1hwYdG8lgftheqN8OOGhcjJrXEkeQh5D
JONKKSAuNBQMknIFzsW7YTYJCMejxD2IBlxQHCFEEo3s8FlgTHCrP3QyzkX/7Emb9bne
bi4pGxk2CTzv79Sr1JYK2TV92fxEe1RnSlp/Y=
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Sender: jer.gentoo@gmail.com
Received: by 10.204.8.199 with SMTP id i7mr1506874bki.37.1255039435195; Thu,
08 Oct 2009 15:03:55 -0700 (PDT)
In-Reply-To: <4ACE5AD2.1020306@gentoo.org>
References: <4AC20C83.3050904@gentoo.org>
<1254916467.6236.11.camel@blackhole.cddr.org>
<4ACE5AD2.1020306@gentoo.org>
Date: Thu, 8 Oct 2009 17:03:55 -0500
X-Google-Sender-Auth: 45f5ed7528dba817
Message-ID: <90b936c0910081503h29bb0bbale75a059cffb178df@mail.gmail.com>
Subject: Re: [gentoo-dev] Unused ebuild built_with_use cleanup
From: Jeremy Olexa <darkside@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: c61959b3-1b3c-4c2c-8ff8-a287d5a0b8cd
X-Archives-Hash: 5eaf20996a200946e5f91f4200592dd0
On Thu, Oct 8, 2009 at 4:34 PM, Petteri R=C3=A4ty <betelgeuse@gentoo.org> w=
rote:
> Stelian Ionescu wrote:
>> On Tue, 2009-09-29 at 16:32 +0300, Petteri R=C3=A4ty wrote:
>>> I wrote a script to check which ebuilds use built_with_use and have
>>> keywords in never versions making the ebuild unused. This means that
>>> neither arch or ~arch users are likely to install the ebuild. The scrip=
t
>>> and the list of ebuilds is attached. I plan on removing all these
>>> ebuilds two weeks from now unless a reason is given why not to. If you
>>> see an ebuild on the list that should be kept, please migrate it to EAP=
I
>>> 2. If you need assistance in migrating, I can help. With these gone
>>> built_with_use usage will be down to about 600:
>>
>> built_with_use shouldn't be removed until EAPI=3D3 gets approved because
>> currently there's no good way to emulate "--missing true|false|die"
>> yes, I can use something like this in sbcl:
>> || ( <sys-libs/glibc-2.6[nptl] >=3Dsys-libs/glibc-2.6 )
>> but not all its use cases may be this simple
>>
>
> Even this is wrong because:
>
> betelgeuse@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 I=
USE
> nls
>
> For most packages old versions are not kept around so just doing
>>=3Dcat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come
> across a case that couldn't be done with EAPI 2 yet. Granted the atoms
> can be a bit cleaner with EAPI 3 but considering how much zmedico slacks
> in implementing it, it's best to do migrating now with EAPI 2 than EAPI
Comments like these are not acceptable. Zac works his tail off on
portage. Please refrain from such comments in the future.
-Jeremy
> 3 in the far future.
>
> Regards,
> Petteri
>
>