add tip when packages are marked as upgradable #3707
Conversation
IanButterworth
force-pushed
the
ib/upgradable_tip
branch
from
fb92811 to
323b951
Compare
| if outdated && !no_packages_upgradable | ||
| printpkgstyle(io, :Info, """ | ||
| If a package is marked by $upgradable_indicator but not upgrading, the resolver may \ | ||
| have other less optimal solutions that do so. |
There was a problem hiding this comment.
the resolver may have other less optimal solutions that do so.
I don't really understand what this means.
There was a problem hiding this comment.
Suggestion: "If a package is marked by $upgradable_indicator but not upgrading, it was likely restricted by a secondary dependency" (right? isn't that the only case where this would show up?)
There was a problem hiding this comment.
No it could be that the resolver has multiple solutions, but the one it went for was the one that changed the least. In that case force adding a version should work but downgrade more
There was a problem hiding this comment.
Is that due to the preserve argument defaulting to all?
| You can try the following (in recommended order): | ||
| - setting compat for the package at the desired version and running `update` again. | ||
| - forcing by `add Foo@(version)`, but a following `upgrade` may downgrade again. | ||
| - forcing by `pin Foo@(version)`. Pinning avoids downgrade but may be too inflexible to maintain. |
There was a problem hiding this comment.
but may be too inflexible to maintain.
Same here, not sure what this means.
There was a problem hiding this comment.
Suggestions:
To upgrade this package, you can try one of the following (in recommended order):
- Add compat entry with `compat (Package) (version)` for the package at the desired version and run `update` again.
- Temporarily force the new version with `add Foo@(version)`, but a future `upgrade` may revert it.
- Permanently force the version with `pin Foo@(version)`, but you will need to manually change this to upgrade in the future.
This comes up quite frequently so perhaps it needs more docs in situ.
It's quite verbose, but only shows on
st --outdated, which seems to be the place the confusion usually lands.