-----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-----