# Two types of blocked updates/upgrades of packages in 1.8

**URL:** <https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474>\
**Category:** General Usage\
**Tags:** package\
**Created:** [August 8, 2022, 1:30pm UTC](https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474 "2022-08-08T13:30:10Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![zdenek\_hurak](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zdenek_hurak/32/53118_2.png) [@zdenek\_hurak](https://discourse.julialang.org/u/zdenek_hurak)\
**Post date:** [August 8, 2022, 1:30pm UTC](https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474/1 "2022-08-08T13:30:11Z")

</div>

In the latest release candidate (v1.8.0-rc3) I can notice a new feature of the package manager, namely, after listing all packages in the given environment with `status`, I get this as the final line:

```julia
Info Packages marked with ⌃ and ⌅ have new versions available, but those with ⌅ cannot be upgraded. To see why use `status --outdated

```

Following the advice, I type

```julia
(@v1.8) pkg> status --outdated
Status `~/.julia/environments/v1.8/Project.toml`
⌃ [961ee093] ModelingToolkit v8.11.0 (<v8.18.6)
⌅ [f27b6e38] Polynomials v2.0.25 (<v3.1.6): IntervalRootFinding
⌃ [0c5d862f] Symbolics v4.3.0 (<v4.10.3)

```

Now, what have I learnt? While I know how to interpret the fact that a newer version of `Polynomials` is blocked by `IntervalRootFidoing`, I have no idea how to interpret the blocking of `ModelingToolkit` and `Symbolics`. The last line of `status` listing explicitly says that `Polynomials` cannot be updated, but doesn’t this say, albeit implicitly, that `ModelingToolkit` and `Symbolics` can? But how can I learn what is blocking the update?

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [August 8, 2022, 1:49pm UTC](https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474/2 "2022-08-08T13:49:41Z")

</div>

Have you done `up`?

In general to learn what (if anything) block installation of a specific update, do `add Package@X.Y.Z` to add a specific version. In your case e.g. `add Symbolics@4.10`

(Incidentally it looks like you’re installing everything into your default environment, which is generally a bad idea - you should work with project specific environments instead and keep the default environment for dev tools like Revise, Pluto, IJulia etc. to avoid version conflicts as much as possible and benefit from reproducibility of your analysis environments).

---

<div class="post-metadata">

**Author:** ![zdenek\_hurak](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zdenek_hurak/32/53118_2.png) [@zdenek\_hurak](https://discourse.julialang.org/u/zdenek_hurak)\
**Post date:** [August 8, 2022, 2:14pm UTC](https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474/3 "2022-08-08T14:14:55Z")

</div>

Yes, I have done `up` before reporting this issue.

Thanks for the advice to use `add Symbolics@4.10`. Indeed, it does produce some detailed report about unsatisfiable requirements.

You have correctly identified that I still keep the bad habit of having one large `env` for everyday work. I should follow your advice to keep just a light one and I easily believe that this type of problems would be reduced.

Anyway, my original issues can perhaps still be regarded valid, cannot it? In the listing following the `status` command, some package are labelled as unupgradable. And there are two types of such packages, distinguished with graphical symbols. While `status --outdated` does help to find the source of the blocking for one type, it says nothing about the other type. Perhaps some better wording of the final sentence after the `status` listing might help dispel confusion.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [August 8, 2022, 2:32pm UTC](https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474/4 "2022-08-08T14:32:40Z")

</div>

Yes, I admit I don’t really see why the tilde without bar is shown when a package is held back, maybe I’ve been sitting in front of my screen for too long but I can’t work it out from the explanation in the docs:

[https://pkgdocs.julialang.org/dev/api/#Pkg.status](https://pkgdocs.julialang.org/dev/api/#Pkg.status)

which explicitly say:

> Packages marked with `⌃` have new versions that can be installed, e.g. via [`Pkg.up`](https://pkgdocs.julialang.org/dev/api/@ref). Those marked with `⌅` have new versions available, but cannot be installed due to compatibility conflicts with other packages. To see why, set the keyword argument `outdated=true`.

So it seems you shouldn’t see `^` when conflicts prevent an update. Maybe @kristoffer.carlsson can help?

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [August 10, 2022, 1:31pm UTC](https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474/5 "2022-08-10T13:31:29Z")

</div>

There is nothing directly holding the package back but there might be other reasons why the package cannot be upgraded. Without doing a full resolve it is impossible to tell so the `^` is a best effort.

---

<div class="post-metadata">

**Author:** ![digital\_carver](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/digital_carver/32/33818_2.png) [@digital\_carver](https://discourse.julialang.org/u/digital_carver)\
**Post date:** [September 22, 2022, 6:09am UTC](https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474/6 "2022-09-22T06:09:06Z")

</div>

> [@kristoffer.carlsson](#):
>
> There is nothing directly holding the package back but there might be other reasons why the package cannot be upgraded.

Can you mention what those reasons might be?

> [@kristoffer.carlsson](#):
>
> Without doing a full resolve it is impossible to tell so the `^` is a best effort.

Would a manual `Pkg.resolve()` help settle these, so that they either become actually upgradeable or marked with `⌅`?

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [September 22, 2022, 6:43am UTC](https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474/7 "2022-09-22T06:43:18Z")

</div>

This is a caret `^`. This is a tilde `~`.

This comment is late and unnecessary, but the Swedish proverb “fel ska va fel” (“wrong must be wrong”) is my core directive.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 22, 2022, 2:31pm UTC](https://discourse.julialang.org/t/two-types-of-blocked-updates-upgrades-of-packages-in-1-8/85474/8 "2022-09-22T14:31:54Z")

</div>

> [@digital\_carver](#):
>
> Can you mention what those reasons might be?

Upgrading the package might downgrade some other package is one example.

> [@digital\_carver](#):
>
> Would a manual `Pkg.resolve()` help settle these, so that they either become actually upgradeable or marked with `⌅`?

In theory it would be possible to go through all packages with `^`, check with the resolver if they can be upgraded to a higher version without changing anything. In a large project with many outdated packages this might get pretty expensive though.