| Summary: | sys-apps/portage-2.1.10.3 autounmask message | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Łukasz Stelmach <stlman> |
| Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | pacho |
| Priority: | Normal | ||
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 376695 | ||
(In reply to comment #0) > [...] > IMHO only the selected and possibly earlier versions > (<=net-misc/hashcash-1.22-r1) should be enabled to prevent sudden problems > after mass upgrade. With the same argument people got me to change it from '=' to '>='. The problem with any version than the '=' version is that emerge doesn't know if it's going to satisfy all dependencies on this package. That's why it doesn't use the '<' versions. It also doesn't use '>' if there is a higher version that the '=' version. It does that only if the '=' version is the latest version (in its slot). The reason to use '>=' in this case is that packages tend to keep working with newer versions of their dependencies. For both '=' and '>=' there are scenarios where they cause problems. I still think '>=' is better than '=', while '<=' is a bad idea. For default behavior, I think '>=' is good. I supposed we could add an option the makes it use '=' instead. Using '<=' doesn't seem very useful to me, since it's unlikely that the package will ever need to be downgraded. Upgrades are quite common, which is what makes '>=' really useful. Actually I'm fine with '='. I am only afraid of unexpected unstable upgrades. If I install unstable version then: * it's probably quite important for me so I keep track of upgrades by myself * it's not too important as I install the package to use it once in a while and it is O.K. for me to upgrade it the moment there is no more ebuild for the version I have installed and emerge shows (am I correct) that any newer version is masked. One possible undesirable scenario is that you'll have a package which only has unstable keywords and if you unmask one version using '=' then you're never going to see updates for that package and emerge won't give you any warning, even if the version that you have installed gets removed from the tree. (In reply to comment #3) > Actually I'm fine with '='. I am only afraid of unexpected unstable upgrades. > If I install unstable version then: > > * it's probably quite important for me so I keep track of upgrades by myself > > * it's not too important as I install the package to use it once in a while and > it is O.K. for me to upgrade it the moment there is no more ebuild for the > version I have installed and emerge shows (am I correct) that any newer version > is masked. The single package secnario is not the reason for autounmask to exist. These cases can be easily managed by hand if you want more control. --autounmask is more useful for stuff like unmasking the next version of your favorit desktop envorionment. In this case you're probably going to miss updates with '=' and you're going to see conflicts when deps are updated. Why about using "=" or ">=" depending on what we use when running emerge? For example, if I run: emerge -1av =gnome-base/gnome-panel-2.32.1-r2 I would prefer to see it unmasked only with "=" but, if I use ">=" or nothing, current behavior would be ok (In reply to comment #6) > Why about using "=" or ">=" depending on what we use when running emerge? For > example, if I run: > emerge -1av =gnome-base/gnome-panel-2.32.1-r2 > > I would prefer to see it unmasked only with "=" but, if I use ">=" or nothing, > current behavior would be ok That seems pretty reasonable. We can use code like this to find the most specific argument atom that matched a given pkg: self._dynamic_config.sets[pkg.root]["__non_set_args__"].findAtomForPackage(pkg) *** This bug has been marked as a duplicate of bug 379333 *** |
The autounmask message that emerge shows if a package needs a "~" keyword suggests making the selected and future versions unmasked like: The following keyword changes are necessary to proceed: #required by hashcash (argument) >=net-misc/hashcash-1.22-r1 ~amd64 IMHO only the selected and possibly earlier versions (<=net-misc/hashcash-1.22-r1) should be enabled to prevent sudden problems after mass upgrade. Reproducible: Always