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

Reply via email to