From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-67013-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 A79D313877A
for <garchives@archives.gentoo.org>; Sun, 27 Jul 2014 21:27:07 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id C3CCAE0DBA;
Sun, 27 Jul 2014 21:27:03 +0000 (UTC)
Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id E46FBE0B91
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jul 2014 21:27:02 +0000 (UTC)
Received: by mail-qg0-f51.google.com with SMTP id a108so7497575qge.24
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jul 2014 14:27:02 -0700 (PDT)
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=M4LEf7zrV8Ft2iQnWQtsAyayJsyz0ZdFt3XKZ5S69eg=;
b=QyaYSzLihx0Uon/xKPFdm4zz9fejO6Q++oqGrDjImya/+AMf2lUQHqUr+Af4Y0Pwdr
MWAtsc5Qy9WBAK9j7Saj7xye77SQ+H0GfhQ80fv8/ZtR4rs/hLe8ZrUOMhlzzFqfV1Kl
W1dh30PAAUJKWN8Bwpux9IhVKvWQvlziv+ZWBep/kEgz82NmHH2DGUXoqnm2mXpLV2Dz
rtsSHKHI011EAys02Y04OH5SyIM/UzjComjJKfK0eF4yAi2/HOHM41xpEMykv8Gr6ypn
p7G4Opck33i/rAH1v5R0ROxgTTBOojKsNEnXHcrWUc7ZvRrvd7HVVQp5Hj1pvJ2FEIZt
V88g==
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.140.30.73 with SMTP id c67mr52643410qgc.16.1406496422124;
Sun, 27 Jul 2014 14:27:02 -0700 (PDT)
Received: by 10.140.44.34 with HTTP; Sun, 27 Jul 2014 14:27:02 -0700 (PDT)
In-Reply-To: <20140727215642.3bbd0826@googlemail.com>
References: <53CD6BED.10603@gentoo.org>
<53CD8BBA.2010605@gentoo.org>
<53D5072E.3030305@gentoo.org>
<CAGfcS_k7gYpC6DnF3TJLKXb9fa0f2ix4Eap5V2BADRZWUD=0uw@mail.gmail.com>
<20140727222429.3febdefa@pomiot.lan>
<20140727205113.9578.qmail@stuge.se>
<20140727215642.3bbd0826@googlemail.com>
Date: Mon, 28 Jul 2014 09:27:02 +1200
Message-ID: <CAATnKFB=LOnGYn2OPJCxE8WCh9xideek9jPXynzhAWoSSJN=YA@mail.gmail.com>
Subject: Re: [gentoo-dev] don't rely on dynamic deps
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: multipart/alternative; boundary=001a113a35a49e636104ff3377a0
X-Archives-Salt: 77b2468f-48ba-4a38-8d02-79642f01ba94
X-Archives-Hash: ef8bb0b07acf96807a44ed39d6b07e72
--001a113a35a49e636104ff3377a0
Content-Type: text/plain; charset=UTF-8
On 28 July 2014 08:56, Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
wrote:
> > To me it seems like a simple data model bug that vdb does not get
> > updated to reflect the new situation after step 2 above.
>
> Rewriting VDB won't help if the user doesn't sync at the right time.
>
Indeed. pkgmove has this problem solved with a mass of quarterly move
files, but I'm not sure I'd want to have
a) However many `depchange` entries required to make it happen linger on
for all eternity in some cruft file just in case people don't sync more
than once every 2 years: ( Yes, we still have an updates/1Q-2009 file for
people stuck in a time warp who need change updates )
b) The burden of maintainers having to manually update that index. ( That's
effectively what the -r1.1 and INSTALL_FROM proposals amount to )
The only saving grace here if we applied this strategy, is we could
conceivably generate the index in an automated fashion due to ebuild edits
usually being more obvious to an SCM than a move is. ( And you could
conceivably generate them by simply comparing snapshot diffs without any
SCM involvement )
--
Kent
*KENTNL* - https://metacpan.org/author/KENTNL
--001a113a35a49e636104ff3377a0
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 28 July 2014 08:56, Ciaran McCreesh <span dir=3D"ltr"><<a href=3D"mai=
lto:ciaran.mccreesh@googlemail.com" target=3D"_blank">ciaran.mccreesh@googl=
email.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">> To me it seems like a s=
imple data model bug that vdb does not get<br>
> updated to reflect the new situation after step 2 above.<br>
<br>
</div>Rewriting VDB won't help if the user doesn't sync at the righ=
t time.<div class=3D"yj6qo ajU"><div id=3D":4mw" class=3D"ajR" tabindex=3D"=
0"></div></div></blockquote></div><br></div><div class=3D"gmail_extra">Inde=
ed. pkgmove has this problem solved with a mass of quarterly move files, bu=
t I'm not sure I'd want to have <br>
<br>a)=C2=A0 However many `depchange` entries required to make it happen li=
nger on for all eternity in some cruft file just in case people don't s=
ync more than once every 2 years:=C2=A0 ( Yes, we still have an updates/1Q-=
2009 file for people stuck in a time warp who need change updates )<br>
<br></div><div class=3D"gmail_extra">b) The burden of maintainers having to=
manually update that index. ( That's effectively what the -r1.1 and IN=
STALL_FROM proposals amount to )<br><br></div><div class=3D"gmail_extra">Th=
e only saving grace here if we applied this strategy, is we could conceivab=
ly generate the index in an automated fashion due to ebuild edits usually b=
eing more obvious to an SCM than a move is.=C2=A0 ( And you could conceivab=
ly generate them by simply comparing snapshot diffs without any SCM involve=
ment )<br>
<br><br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extr=
a"><br clear=3D"all"><br>-- <br><div dir=3D"ltr"><div>Kent<font size=3D"1">=
<b> <br><br></b></font></div><div><span style=3D"color:rgb(204,204,204)"><f=
ont size=3D"1"><b>KENTNL</b> - <a href=3D"https://metacpan.org/author/KENTN=
L" target=3D"_blank">https://metacpan.org/author/KENTNL</a></font></span><b=
r>
</div><div><br></div></div>
</div></div>
--001a113a35a49e636104ff3377a0--