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-50454-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; Thu, 15 Mar 2012 21:32:02 +0000 (UTC)
Received: by werm13 with SMTP id m13so3991556wer.40
for <gentoo-dev@lists.gentoo.org>; 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 <reavertm@gmail.com>
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: <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
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--