On 06/11/2013 17:26, Kent Fredric wrote: > > On 7 November 2013 04:15, Ian Stakenvicius <[email protected] > <mailto:[email protected]>> wrote: > > > 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. > > > Theres another scenario not listed here which can still happen: > > The end user has a copy of icu-49.ebuild somewhere in their portage > layout still. > > Either this is due to a published overlay containing it, or them locally > maintaining their own private overlay. > > The "update world" thing *may* still work in such a circumstance, but > you'd have to change the policy to say "Update to a something that is in > ::gentoo before merging packages from ::gentoo", which is getting a bit > logically messy. > > Even then, it may not be apparent that there is a problem, for instance, > if they have the overlay in place, *AND* they've locally masked newer > versions of icu, for some reason ( perhaps they have 3rd party software > they're locally maintaining that requires an older version of icu ). > > Here, the *only* sane approach is for firefox to declare it needs a > certain version of icu as a minimum, regardless of what is, and what > isn't visible in tree, so that the end user at very least gets told > "firefox needs this", and its then their responsibility to sort out the > problem if they've caused one.
I agree with this sentiment. It's always been my view that the needs of a package are driven by the package itself, not by the tree. Rationale: A package will build and run as long as it's own requirements are met regardless of what the tree states. We have layman overlays and user's own overlays. Whilst these are not 100% supported by Gentoo they are not banned either. They are also not "barely tolerated", it's more a case of overlays are not a problem and users are welcome to use them as long as they don't conflict with or break the tree for that user. This needn't be onerous. Presumably ebuild maintainers read the README and Changelog, these often state the versions of deps the package supports. Take that information and put it in the ebuild. Maintainers are under no obligation to provide the absolute minimum version of a dep, only at least one that will work. If the user decides to make other versions available to his system by whatever means, then portage can deal with it by and large transparently. -- Alan McKinnon [email protected]
