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 72867138010 for ; Tue, 18 Sep 2012 22:02:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A575821C047; Tue, 18 Sep 2012 22:02:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D3CE421C01F for ; Tue, 18 Sep 2012 22:01:21 +0000 (UTC) Received: from pomiocik.lan (77-254-69-147.adsl.inetia.pl [77.254.69.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id E410833C898; Tue, 18 Sep 2012 22:01:19 +0000 (UTC) Date: Wed, 19 Sep 2012 00:01:21 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Cc: ciaran.mccreesh@googlemail.com Subject: Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal Message-ID: <20120919000121.52d12484@pomiocik.lan> In-Reply-To: <20120918223719.790e1477@googlemail.com> References: <20120916135211.GC23030@localhost> <20120918102551.500ff19b@pomiocik.lan> <20120918092426.GA5384@localhost> <20568.16682.31115.233591@a1i15.kph.uni-mainz.de> <50584559.2000909@gmail.com> <20568.20091.816189.902403@a1i15.kph.uni-mainz.de> <5058CAC5.5080706@gentoo.org> <20120918202909.7b238573@googlemail.com> <5058CE43.6000501@gentoo.org> <20120918204433.52af8bcd@googlemail.com> <20120918225104.567ca679@pomiocik.lan> <20120918215355.7ee46043@googlemail.com> <20120918230606.03d994f2@pomiocik.lan> <20120918220843.39868fd0@googlemail.com> <20120918233429.277a4726@pomiocik.lan> <20120918223719.790e1477@googlemail.com> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.12; x86_64-pc-linux-gnu) 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-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/XUZ==i3.b6ItCPwRpec8jSi"; protocol="application/pgp-signature" X-Archives-Salt: 5bf2d373-5e71-4e6d-acc7-4be3732de6a8 X-Archives-Hash: c66db401b8a365de15bb4fb6e0e47f51 --Sig_/XUZ==i3.b6ItCPwRpec8jSi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 18 Sep 2012 22:37:19 +0100 Ciaran McCreesh wrote: > On Tue, 18 Sep 2012 23:34:29 +0200 > Micha=C5=82 G=C3=B3rny wrote: > > On Tue, 18 Sep 2012 22:08:43 +0100 > > Ciaran McCreesh wrote: > > > On Tue, 18 Sep 2012 23:06:06 +0200 > > > Micha=C5=82 G=C3=B3rny wrote: > > > > But didn't we already point out that we can't have them in > > > > RDEPEND since they introduce conflicts? > > >=20 > > > You are missing a basic and important part of how dependency > > > resolution works: currently, cycles consisting purely of RDEPENDs > > > are ignorable. > >=20 > > So, what do we lose? If PDEP comes 'ASAP' officially, I believe that > > we actually gain RDEPs which can be actually trusted. >=20 > "ASAP" is a weaker guarantee that RDEPENDs currently have -- RDEPENDs > currently have the weakest guarantee necessary to ensure that they can > be trusted. It's also a useless guarantee, since "ASAP" can be > arbitrarily late. And can't RDEPENDs be arbitrarily late if there is a cycle? --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/XUZ==i3.b6ItCPwRpec8jSi Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlBY7zEACgkQfXuS5UK5QB26bwP/RO130/Cz+iYs2H5mV3IMn1el cMI0pd0wTWhoUgDkGE8abbfrh0zfwM8hgpG/t2b8XkZ21t6kgRKtK8egk3HEKl8k LhVMbRy4f1Zy0/HF54I8l77KYSH1U7DrAOu4Rb2zH3viGKyE7WDLUBylWk9yRpC4 Zwy4K7hQLbZB8azKmLw= =KpSZ -----END PGP SIGNATURE----- --Sig_/XUZ==i3.b6ItCPwRpec8jSi--