From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-63415-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 1B253138247
	for <garchives@archives.gentoo.org>; Wed,  6 Nov 2013 15:26:36 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id D24FAE099F;
	Wed,  6 Nov 2013 15:26:31 +0000 (UTC)
Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id B6EC1E0998
	for <gentoo-dev@lists.gentoo.org>; Wed,  6 Nov 2013 15:26:30 +0000 (UTC)
Received: by mail-ve0-f174.google.com with SMTP id pa12so3716125veb.33
        for <gentoo-dev@lists.gentoo.org>; Wed, 06 Nov 2013 07:26:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=KE7PiTvuXr71U1Vd5J/EgqHsqrG0tWMwqsbLnl6CtrU=;
        b=GYiN6gkyLSsXm8Ei+wR4U5rAwHOjJXVmuwmDKD8+I0PQMTFUNLqS5Gjkah9LPxA0pv
         3iR/Fkw9TSxU/V7YSeeIYD74wxrJ6IQUXYUT8yvjhGDmOynTYrUGKLdWt3CK9ZoHbOCY
         dEc5+LvG0GRDlxivF1tWwcXjZuPhQ4gFC+zlI4aEjOZ+UQmjwan12xAmkL+YIM0hobgf
         /ZNmknTUcXM8++p21UaxX+Yw9A2LPQHpcZl6doDc6SXJOZMOLVpSi7btQknFl99RAQ9H
         sbHhuPUcg3ZTxr61INNsPI8vhtC9/3k2imNbzOTIL75f20KCv7zrpSUYydXSJ6OiruO2
         nT7w==
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
X-Received: by 10.52.97.138 with SMTP id ea10mr2362619vdb.31.1383751589818;
 Wed, 06 Nov 2013 07:26:29 -0800 (PST)
Received: by 10.58.7.10 with HTTP; Wed, 6 Nov 2013 07:26:29 -0800 (PST)
In-Reply-To: <527A5D22.10009@gentoo.org>
References: <527A5D22.10009@gentoo.org>
Date: Thu, 7 Nov 2013 04:26:29 +1300
Message-ID: <CAATnKFCcmQM-AhYa3DNyOKPyWaGcc4h_ALVh+p853HkKTNaFog@mail.gmail.com>
Subject: Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: multipart/alternative; boundary=20cf307f38f8f7f75a04ea83c527
X-Archives-Salt: be441532-139a-4e51-8c0a-235af741180a
X-Archives-Hash: 1462bd06697f9fb54f1f821f545e6ec6
--20cf307f38f8f7f75a04ea83c527
Content-Type: text/plain; charset=UTF-8
On 7 November 2013 04:15, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> The bug that was filed, is that a user didn't do a full emerge -uDN
> @world prior to emerging (upgrading?) firefox, and they had icu-49
> already installed.  Because the firefox dep didn't have a minimum
> version, portage didn't see upgrading icu as a requirement before
> firefox emerged.
>
Theres another scenario not listed here which can still happen:
The end user has a copy of icu-49.ebuild somewhere in their portage layout
still.
Either this is due to a published overlay containing it, or them locally
maintaining their own private overlay.
The "update world" thing *may* still work in such a circumstance, but you'd
have to change the policy to say "Update to a something that is in ::gentoo
before merging packages from ::gentoo", which is getting a bit logically
messy.
Even then, it may not be apparent that there is a problem, for instance, if
they have the overlay in place, *AND* they've locally masked newer versions
of icu, for some reason ( perhaps they have 3rd party software they're
locally maintaining that requires an older version of icu ).
Here, the *only* sane approach is for firefox to declare it needs a certain
version of icu as a minimum, regardless of what is, and what isn't visible
in tree, so that the end user at very least gets told "firefox needs this",
and its then their responsibility to sort out the problem if they've caused
one.
-- 
Kent
--20cf307f38f8f7f75a04ea83c527
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 7 November 2013 04:15, Ian Stakenvicius <span dir=3D"ltr"><<a href=3D=
"mailto:axs@gentoo.org" target=3D"_blank">axs@gentoo.org</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<br>
The bug that was filed, is that a user didn't do a full emerge -uDN<br>
@world prior to emerging (upgrading?) firefox, and they had icu-49<br>
already installed. =C2=A0Because the firefox dep didn't have a minimum<=
br>
version, portage didn't see upgrading icu as a requirement before<br>
firefox emerged.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">Theres another scen=
ario not listed here which can still happen:<br><br></div><div class=3D"gma=
il_extra">The end user has a copy of icu-49.ebuild somewhere in their porta=
ge layout still.<br>
<br>Either this is due to a published overlay containing it, or them locall=
y maintaining their own private overlay.<br><br></div><div class=3D"gmail_e=
xtra">The "update world" thing *may* still work in such a circums=
tance, but you'd have to change the policy to say "Update to a som=
ething that is in ::gentoo before merging packages from ::gentoo", whi=
ch is getting a bit logically messy.<br>
<br></div><div class=3D"gmail_extra">Even then, it may not be apparent that=
 there is a problem, for instance, if they have the overlay in place, *AND*=
 they've locally masked newer versions of icu, for some reason ( perhap=
s they have 3rd party software they're locally maintaining that require=
s an older version of icu ).<br>
<br></div><div class=3D"gmail_extra">Here, the *only* sane approach is for =
firefox to declare it needs a certain version of icu as a minimum, regardle=
ss of what is, and what isn't visible in tree, so that the end user at =
very least gets told "firefox needs this", and its then their res=
ponsibility to sort out the problem if they've caused one.<br>
</div><div class=3D"gmail_extra"><br>-- <br>Kent<br>
</div></div>
--20cf307f38f8f7f75a04ea83c527--