Haskell overlay has a lot of depends in form RDEPENDS=">=foo-1 <foo-2" When foo-2 version is added to the overlay I usually install foo-2 with --nodeps and fix all ebuilds to support '<foo-2'. If someone else will accidentaly reintroduce '<foo-2' in some ebuilds for installation I would like not to have 'foo' silently downgraded. Currently I use package.mask for it by putting <foo-2 to it. Which is 135 lines long only for haskell overlay on my dev machine. I'd like to have that list for free by option like '--forbid-downgrades'. paludis has it as a default behaviour. I think it's a bit harsh for a user, but for a dev like should be exactly the right thing. The working semantics would be to build ephemeral package.mask of the following structure: for each (cpv, slot) in installed_packages add a masked line in form "<#{CPV}:#{SLOT}" side note: [blind mode] In theory it could speed dependency resolution a bit by if portage would not consider packages with older versions as existing at all (but it will degrade error messages). Thus the available options could be --forbid-downgrades=yes|no|blind (with 'yes' by default)
(In reply to Sergei Trofimovich from comment #0) > Thus the available options could be > --forbid-downgrades=yes|no|blind (with 'yes' by default) Maybe also add a "soft" behavior, so that downgrades are allowed in order to satisfy dependencies.
I don't like this. What I would expect out of an option named "forbid-downgrades" is that it will not consider downgrades for resolving my depgraph in this run. What I think would be better would be an --automask that takes an argument like "downgrades".
> Thus the available options could be > --forbid-downgrades=yes|no|blind (with 'yes' by default) I meant "with 'no' by default" no save behaviour.
Hmm, I recall emerge had a --upgradeonly option in the past. It was removed due to some problems it could cause. What is different about this new option other than its name. It sounds like it would just re-introduce the same behavior.
(In reply to Brian Dolbec from comment #4) > Hmm, I recall emerge had a --upgradeonly option in the past. It was removed > due to some problems it could cause. > > What is different about this new option other than its name. It sounds like > it would just re-introduce the same behavior. I don't know the past problems. Do you have a link that describes the problem?
