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 ) id 1S8IHl-0006iq-5H for garchives@archives.gentoo.org; Thu, 15 Mar 2012 21:32:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 47130E0AB6; Thu, 15 Mar 2012 21:32:28 +0000 (UTC) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 53C79E09EB for ; Thu, 15 Mar 2012 21:32:02 +0000 (UTC) Received: by werm13 with SMTP id m13so3991556wer.40 for ; Thu, 15 Mar 2012 14:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to :disposition-notification-to:mime-version:content-type :content-transfer-encoding:message-id; bh=8lrY42/Ca+GnZU9gyzOGeSTQnhBf9kScxpoJepOdJw8=; b=Mxare5GgNlduir4P6F1IXaLm8qIMUcA410CAoot6+Bb2OgI8GNk2ftr4Q+jUs8Adc1 wFqrmqvAGf9Vo/aXSKp1k4Sr4OApwVrUdvEapWVzHpRVt9h975eVYZ9hAT2RxosTIhyn zK7U+RsNClx2WslzNyf5T9ZQYpQC2vmypNOS8/fJMXkZTw9TGsdMumqLUrXDOnlBTUO2 KWfF3RSs3dNLpqY9s+mXM8Vqp+t6AAP+UosIUueE73G+kn/qh0KrxKH38kGCvSqca4wf LHekpKD/6Lurd8HY6BXTEl8Tyf43/Rvp/LHoRZqP998hOOxWpNK8JTi4T5vuRDMdtAd/ fICw== Received: by 10.180.84.164 with SMTP id a4mr828001wiz.2.1331847121345; Thu, 15 Mar 2012 14:32:01 -0700 (PDT) Received: from lebrodyl.localnet (89-78-60-134.dynamic.chello.pl. [89.78.60.134]) by mx.google.com with ESMTPS id df3sm8233426wib.1.2012.03.15.14.31.59 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 14:32:00 -0700 (PDT) From: Maciej Mrozowski To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Deprecate EAPI1? Date: Thu, 15 Mar 2012 22:31:49 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.1-gentoo-r2; KDE/4.8.1; x86_64; ; ) References: <1331467306.11661.2.camel@belkin4> <4F5CC159.1020602@gentoo.org> <20120312004935.GB7579@localhost> In-Reply-To: <20120312004935.GB7579@localhost> 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: multipart/signed; boundary="nextPart6533165.oB4CEL0ll2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203152231.49461.reavertm@gmail.com> X-Archives-Salt: 0110fc4a-0d79-4053-b595-8978ad97bbd0 X-Archives-Hash: e1919aab136659b2d4b328196a66ab73 --nextPart6533165.oB4CEL0ll2 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Monday 12 of March 2012 01:49:35 Brian Harring wrote: > On Sun, Mar 11, 2012 at 04:14:33PM +0100, Ch??-Thanh Christopher Nguy???n= =20 wrote: > > Ciaran McCreesh schrieb: > > >> Is there really much of a benefit to this? I guess for anybody who > > >> runs scripts to mass-manipulate ebuilds it might be helpful, but I > > >> think all the package managers planned on supporting all the EAPIs f= or > > >> quite a while longer. > > >=20 > > > We have to support them indefinitely. It's not possible to uninstall a > > > package whose EAPI is unknown. > >=20 > > Would it be feasible to do a pkg_pretend() check and refuse > > install/upgrade if packages with unsupported EAPI are detected? >=20 > The question should be "is it worth doing it", rather than "can we > hack out something". >=20 > As Ciaran said, PM's are going to be supporting EAPI1 indefinitely In principle, it's actually entirely possible for any PM to start supportin= g=20 exclusively completely API and ABI-breaking EAPI. There's always the problem with self-upgrading software as it needs to some= how=20 predict (and limit) its development to keep upgrade paths. We have this exact problem where I work (with updating basestation SW) and= =20 some solution for this software is to stop being self-upgrading. With external upgrade tool (which would rsync package tree do any=20 vdb/metadata-magic needed) one could replace current PM with latest, API/AB= I- incompatible PM version. Now, it may not really make sense for PM as upgrade process of PM itself is= n't=20 any different from upgrade process of any other package, still it would all= ow=20 any API/ABI-breaking ebuild format changes to be introduced if we really ne= ed=20 them so badly. =2D-=20 regards MM --nextPart6533165.oB4CEL0ll2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk9iX8UACgkQFuHa/bHpVds/gwCfR1tUS1nKnbsen8BSHGKz/NjZ k/UAnA3vVjJaID4viwa+a5u71lEF2fST =i8RG -----END PGP SIGNATURE----- --nextPart6533165.oB4CEL0ll2--