Summary: | add ability to forbid package downgrades | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sergei Trofimovich (RETIRED) <slyfox> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sergei Trofimovich (RETIRED)
2014-10-27 20:13:38 UTC
(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? |