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 B3B2B138247 for ; Wed, 6 Nov 2013 15:16:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C82DE0995; Wed, 6 Nov 2013 15:16:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AA31FE0946 for ; Wed, 6 Nov 2013 15:16:08 +0000 (UTC) Received: from [192.168.1.160] (CPE002401f30b73-CM001cea3ddad8.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id AC0AC33DA86 for ; Wed, 6 Nov 2013 15:16:07 +0000 (UTC) Message-ID: <527A5D22.10009@gentoo.org> Date: Wed, 06 Nov 2013 10:15:46 -0500 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Thunderbird/17.0.9 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 To: gentoo-dev Subject: [gentoo-dev] Policy-level discussion for minimum versions on dependencies X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: b188468d-facd-4d65-82e1-1c19fd98cd03 X-Archives-Hash: 203e3872032e2e1e69562299ff0f850d -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all... Mozilla had a bug recently ( http://bugs.gentoo.org/show_bug.cgi?id=489838 ) that I think has much wider implications for all packages, and I would like to discuss how to best address this. The synopsis of the situation is that the latest firefox ebuild now depends on icu, specifically icu-50.1 or above. When this version of firefox was added to the tree, the lowest version of icu in the tree was icu-51.0 -- in fact, icu-48 through icu-50 were dropped from the tree about 2 months prior to the new firefox being added. 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. I fully agree with the user and other commenters on the bug, that after --sync'ing a user should be able to 'emerge [-u] firefox' and all necessary dependency updates would be applied. However, it's been a long-standing general practise that if there are no deps in the tree older than what is necessary for a package, that package doesn't need to have a minimum version on the dependency atom. As such, issues similar to this are probably lying in wait all other the place in the tree. To mitigate this, i see three possibilities: 1 - make it clear in documentation for end users that they need to emerge -uDN @world after a --sync, otherwise they may see breakage and if they do it's not a bug when an emerge -uDN @world fixes it. IMO this is not a desirable solution but it best matches what is unofficially required now. 2 - make a policy for developers that they need to add minimum versions on dependency atoms so that their package will trigger dependency updates, for all dependencies that have in the last year (**) had a version in the tree older than what the package needs. This is the most "correct" solution, but requires all devs to do the work. 3 - change portage behaviour s.t. somehow when resolving dependencies it does not consider installed atoms that are missing from the tree to be valid at satisfying a dependency of a package. This would resolve the issue without dev's as a whole needing to do anything different, but would also have unforseen consequences since this is a major behavioural change for portage's dependency resolution. Thoughts? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlJ6XSIACgkQ2ugaI38ACPAWtgEAsiXy5LmYriPMeRanleI7fqNK faU2TwOpvykeYfEwpqQA/AirKpkPwpSp6tGau1PPjeOIGUuz6dZgnL8KkZ/J9JEa =VUYT -----END PGP SIGNATURE-----