Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vcpkg remove does not update the status database after package removal #13097

Closed
rkitover opened this issue Aug 23, 2020 · 10 comments
Closed

vcpkg remove does not update the status database after package removal #13097

rkitover opened this issue Aug 23, 2020 · 10 comments
Assignees
Labels
category:vcpkg-feature The issue is a new capability of the tool that doesn’t already exist and we haven’t committed

Comments

@rkitover
Copy link
Contributor


Is your feature request related to a problem? Please describe.
The Status: field of a package does not get updated from install ok installed immediately after its removal, a subsequent operation such as list is required for the database to be updated.

Proposed solution
It should get updated immediately on a remove.

Additional context
Here is the log from my terminal illustrating the issue:

✔ ~\src\vcpkg\installed\vcpkg [master ≡]
rkitover@epycwin > grep sfml -A 10 .\status
Package: sfml
Version: 2.5.1
Port-Version: 9
Depends: freetype, libflac, libogg, libvorbis, openal-soft, stb
Architecture: x64-windows-static
Multi-Arch: same
Abi: 8dc17b8325a06029c61f264bbfe0f10464b57f6b
Description: Simple and fast multimedia library
Type: Port
Status: install ok installed

✔ ~\src\vcpkg\installed\vcpkg [master ≡]
rkitover@epycwin > vcpkg remove sfml:x64-windows-static
Your feedback is important to improve Vcpkg! Please take 3 minutes to complete our survey by running: vcpkg contact --survey
The following packages will be removed:
    sfml:x64-windows-static
Removing package sfml:x64-windows-static...
Removing package sfml:x64-windows-static... done
✔ ~\src\vcpkg\installed\vcpkg [master ≡]
rkitover@epycwin > grep sfml -A 10 .\status
Package: sfml
Version: 2.5.1
Port-Version: 9
Depends: freetype, libflac, libogg, libvorbis, openal-soft, stb
Architecture: x64-windows-static
Multi-Arch: same
Abi: 8dc17b8325a06029c61f264bbfe0f10464b57f6b
Description: Simple and fast multimedia library
Type: Port
Status: install ok installed

✔ ~\src\vcpkg\installed\vcpkg [master ≡]
rkitover@epycwin > vcpkg list *> $null
✔ ~\src\vcpkg\installed\vcpkg [master ≡]
rkitover@epycwin > grep sfml -A 10 .\status
Package: sfml
Version: 2.5.1
Port-Version: 9
Depends: freetype, libflac, libogg, libvorbis, openal-soft, stb
Architecture: x64-windows-static
Multi-Arch: same
Abi: 8dc17b8325a06029c61f264bbfe0f10464b57f6b
Description: Simple and fast multimedia library
Type: Port
Status: purge ok not-installed
@MVoz
Copy link
Contributor

MVoz commented Aug 23, 2020

this is normal, the status is not immediately updated
repeat the installation command and everything will be ok

@rkitover
Copy link
Contributor Author

I understand that it does not cause problems in terms of functionality, however I would disagree that the database being in an inconsistent state is normal, but that is for you to decide.

@MVoz
Copy link
Contributor

MVoz commented Aug 23, 2020

it's always been that way for as long as I can remember

@linquize
Copy link

This design also causes #10812

@JackBoosY
Copy link
Contributor

@BillyONeal I think it's a vcpkg bug, or it's by design?

@BillyONeal
Copy link
Member

Seems like a bug to me.

@BillyONeal BillyONeal changed the title status database does not get updated immediately on package removal vcpkg remove does not update the status database after package removal Aug 24, 2020
@JackBoosY JackBoosY added the category:vcpkg-bug The issue is with the vcpkg system (including helper scripts in `scripts/cmake/`) label Aug 25, 2020
@ras0219
Copy link
Contributor

ras0219 commented Jan 19, 2021

This is not a bug: the status database is more nuanced than a single file.

Specifically, during execution, vcpkg writes update files that contain "deltas" to the status db. At any given point in time, the database should be considered as the sum of the status file and all update files.

On launch, when loading the status db, vcpkg first performs a compacting step that computes the entire consolidated status file and writes that back out (atomically) to the status database. This is why you observe that running vcpkg list appears to "fix" the status file -- it performs a "gc" from many files down to one.

The reason to not write the database out on every update is that it would make installing N packages an O(N^2) operation -- every install step would need to re-write the binary paragraph of every install step before it. The reason to consolidate is to avoid needing to access O(N) files on every execution.

tldr; not a bug, by design.

@rkitover
Copy link
Contributor Author

Right so, what is the problem with updating the database after every COMMAND, if a command installs multiple packages it can still do that.

@BillyONeal
Copy link
Member

The reason to not write the database out on every update is that it would make installing N packages an O(N^2) operation -- every install step would need to re-write the binary paragraph of every install step before it. The reason to consolidate is to avoid needing to access O(N) files on every execution.

The compressed version of the database could be written as part of vcpkg remove without turning all operations into O(n^2).

@JackBoosY JackBoosY added category:question This issue is a question category:vcpkg-feature The issue is a new capability of the tool that doesn’t already exist and we haven’t committed and removed category:vcpkg-bug The issue is with the vcpkg system (including helper scripts in `scripts/cmake/`) labels Jan 20, 2021
@JackBoosY JackBoosY removed the category:question This issue is a question label Mar 24, 2021
@JackBoosY
Copy link
Contributor

Duplicated to #10812.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:vcpkg-feature The issue is a new capability of the tool that doesn’t already exist and we haven’t committed
Projects
None yet
Development

No branches or pull requests

6 participants