From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A79D313877A for ; 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 ; Sun, 27 Jul 2014 21:27:02 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id a108so7497575qge.24 for ; 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: 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 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> <20140727222429.3febdefa@pomiot.lan> <20140727205113.9578.qmail@stuge.se> <20140727215642.3bbd0826@googlemail.com> Date: Mon, 28 Jul 2014 09:27:02 +1200 Message-ID: Subject: Re: [gentoo-dev] don't rely on dynamic deps From: Kent Fredric 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 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

= On 28 July 2014 08:56, Ciaran McCreesh <ciaran.mccreesh@googl= email.com> wrote:
> To me it seems like a s= imple 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 righ= t time.

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

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 )

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 )

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 )





--
--001a113a35a49e636104ff3377a0--