Skip to content

filesystem: fix upgrade#2022

Merged
Alexpux merged 1 commit intomsys2:masterfrom
lazka:revert-msys2-base-removal
Jun 25, 2020
Merged

filesystem: fix upgrade#2022
Alexpux merged 1 commit intomsys2:masterfrom
lazka:revert-msys2-base-removal

Conversation

@lazka
Copy link
Member

@lazka lazka commented Jun 23, 2020

msys2-base was removed from dash and filesystem, but filesystem gets updated
first and then fails beause it would break dash which hasn't been updated yet.

So add the provides back.

This fixes:

error: failed to prepare transaction (could not satisfy dependencies)
:: installing filesystem (2020.02-3) breaks dependency 'msys2-base' required by dash

msys2-base was removed from dash and filesystem, but filesystem gets updated
first and then fails beause it would break dash which hasn't been updated yet.

So add the provides back.

This fixes:

error: failed to prepare transaction (could not satisfy dependencies)
:: installing filesystem (2020.02-3) breaks dependency 'msys2-base' required by dash
@marler8997
Copy link

So it sounds like filesystem will have to maintain this provides=('msys2-base') for the forseeable future if we want to avoid this error when upgrading filesystem from the current or previous versions to a newer one.

It seems like the better solution would be to fix pacman to handle when provides are removed and the upgraded versions of their dependents (in this case dash) no longer require them.

If pacman is unable to upgrade a package because it has removed a provides that is needed by another package, shouldn't it save that operation and come back to it later after attempting to upgrade the rest of the packages? In this case, it would fail to upgrade filesystem because it no longer provides msys2-base and dash depends on it, but then it could continue on and eventually upgrade dash which will no longer depend on msys2-base then it can come back to any packages that previously failed and retry. It seems like an mechanism like this would be much more robust.

@marler8997
Copy link

For reference, looks like this is the PR that caused the issue: #1984

@lazka
Copy link
Member Author

lazka commented Jun 24, 2020

If pacman is unable to upgrade a package because it has removed a provides that is needed by another package, shouldn't it save that operation and come back to it later after attempting to upgrade the rest of the packages? In this case, it would fail to upgrade filesystem because it no longer provides msys2-base and dash depends on it, but then it could continue on and eventually upgrade dash which will no longer depend on msys2-base then it can come back to any packages that previously failed and retry. It seems like an mechanism like this would be much more robust.

The problem is that we have a "core update group" thingy which gets always update first, which contains filesystem and not dash. pacman can handle this all just fine, we break it by splitting the update into two parts. We need to think about getting rid/reducing the "core update group"..

@marler8997
Copy link

The problem is that we have a "core update group" thingy which gets always update first, which contains filesystem and not dash. pacman can handle this all just fine, we break it by splitting the update into two parts. We need to think about getting rid/reducing the "core update group"..

Oh I see, thanks for that explanation.

@pqnet
Copy link

pqnet commented Jun 24, 2020

For anyone ending up here and looking for a workaround: this is fixed if you upgrade manually dash by running pacman -S dash

nirbheek added a commit to mesonbuild/meson that referenced this pull request Jun 24, 2020
nirbheek added a commit to mesonbuild/meson that referenced this pull request Jun 24, 2020
See: msys2/MSYS2-packages#2022 (comment)

Also kill all MSYS2 processes after the first update, and constantly
print update status.
@Alexpux Alexpux merged commit 20f306e into msys2:master Jun 25, 2020
@lazka
Copy link
Member Author

lazka commented Jun 25, 2020

@Alexpux thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants