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 31367138A2F for ; Fri, 25 Jul 2014 08:52:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0E54CE15BA; Fri, 25 Jul 2014 08:52:00 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 17907E159F for ; Fri, 25 Jul 2014 08:51:59 +0000 (UTC) Received: from [192.168.1.223] (249.135.217.87.dynamic.jazztel.es [87.217.135.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id 715B63400E4; Fri, 25 Jul 2014 08:51:57 +0000 (UTC) Message-ID: <1406278313.20388.9.camel@gentoo.org> Subject: Re: [gentoo-dev] don't rely on dynamic deps From: Pacho Ramos To: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= Cc: gentoo-dev@lists.gentoo.org Date: Fri, 25 Jul 2014 10:51:53 +0200 In-Reply-To: <20140725000627.34d08221@pomiot.lan> References: <53CD6BED.10603@gentoo.org> <201407212153.04605.dilfridge@gentoo.org> <20140721205527.142cb3d5@googlemail.com> <1405976767.1013.9.camel@gentoo.org> <20140725000627.34d08221@pomiot.lan> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.4 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-Transfer-Encoding: 8bit X-Archives-Salt: 09d8f286-e144-4f90-a0b5-e1d8d42b8ce0 X-Archives-Hash: ea11d0a51c28bed3930885f8519cce9c El vie, 25-07-2014 a las 00:06 +0200, Michał Górny escribió: [...] > > Maybe this could be solved by having two kinds of revisions: > > - One would rebuild all as usually (for example, -r1...) > > - The other one would only regenerate VDB and wouldn't change the > > installed files (for example, -r1.1) > > > > But I am not sure if it could be viable from a "technical" point of > > view :( > > I'm afraid it couldn't. The major problem is not knowing *when* to > migrate metadata, portage usually gets that right. The problem is in > getting the correct output which is often near to impossible. > But, isn't it something up to developer in that case? I mean, we should have a list of things that deserve that VDB regeneration and, then, make the -r1.1 revbump instead of the major one.