opam does not remove stale files on upgrade #4419
Comments
|
It should indeed. Is it the same issues than #4207? |
|
Quite possible -- I have no clue about the underlying cause, but the symptoms are the same. Is there a way to ask opam which files it thinks are part of a package, to make it easier to check if something went wrong there? |
|
The command |
|
Hm, that looks as expected for a few random things that I just checked. |
|
I also tried the same upgrade again and this time the file was removed correctly. But sometimes opam seems to lose track of the files it installed, and of course I only notice this waaay later when there is an update which actually removes a file (which is rare for these packages). |
|
I just had the problem again: coq-iris wasn't even installed (it seems it got uninstalled some time ago, not sure when), but stale files still existed that I had to delete manually: This is using a local switch that is symlinked into a whole bunch of directories, maybe that is part of the problem? |
I still don't know how to reproduce this, but when this just occurred again for the "coq-iris" package, I did a quick test with the "coq-stdpp" package: So, opam does know that all these files belong to stdpp. So, even though opam knew about these files, it still did not uninstall them. |
|
is this in a docker container by any chance? I've tried it locally and every files and directories were successfully removed |
|
No, it's directly on my Debian testing system, no docker or other kind of container involved. |
|
Is it possible that another package changes those files ? |
|
Well, it's hard to definitely answer "no" to such a question^^. No other package should do that. I could imagine that deinstalling or reinstalling |
|
I just had this again. What should I do to figure out more about what is happening? To reiterate, I have an opam prefix in a state where I can snapshot the prefix into a tarball and upload it somewhere for you to investigate, but I fear that might affect the results -- at least, after I unpacked the tarball elsewhere on my local system, |
|
Yeah, I have here an affected |
|
It seems like with |
|
@rjbou you added the "can't reproduce" label a while ago. Three months ago I provided detailed instructions to reproduce the problem. Could you have a look and maybe remove the label? :) |
|
Could it be that opam is confused because the parent directory (user-contrib) gets modified by other Coq contribs? |
|
@RalfJung - thanks for the reproduction case, but we've all been rather busy with opam 2.1, which by 10 Mar was "frozen" for anything other than regressions as we were moving towards release candidate. The second, and hopefully final, release candidate was tagged yesterday, so I'm sure this issue will being dealt with as we finalise plans for opam 2.2.0. |
|
Taking a look to changes file, we can see that opam marked the changes made by In fact, in you switch, you are in a state where no package have the information to delete Only The only package that creates a directory is That is the explanation on why you keep stale files. But how you end up with that switch state is still a mystery. |
My guess would be that at an earlier time, opam failed to remove those files, and then the next time I installed coq-stdpp opam was like "ah those files already exist, so I guess I will record coq-stdpp as changing those files". The way the system seems to work, if opam ever gets it wrong it will not be able to ever recover this switch. FWIW after updating to opam 2.1 I am now fighting with "fun" errors like I suspect this is the same problem -- zarith files were not properly deleted when it got uninstalled for an update. (The error at the end is totally wrong, I never run opam as root so it definitely did not ever put anything into /usr/lib/ocaml. It is asking me to delete files that were installed by I assume I have to give up on all my switches and re-create them all from scratch. :( |
|
FWIW I just had this happen again in a switch that I just recently created after updating to opam 2.1 (since as mentioned above, the automatic upgrade entirely failed): a file was removed in a package upgrade, but the file still exists in the opam switch. Is it possible that this has something to do with the fact that this is a local (per-directory) switch that is associated with several directories by symlinking the |
|
I thought this might have to do with me using system ocaml (which has caused trouble in the past), but I just saw the same problem in a switch that does not use system ocaml. I had recently pinned an already installed package to a git repository, and now as part of updating the pin opam decided it had to reinstall everything ("upstream or system changes" in ocaml-variants), and then when it uninstalled that pinned package all its files were left behind. |
|
@RalfJung then the problem may be the same one as I described at #5132 |
I just upgraded the coq-iris package from dev.2020-11-03.3.4cd21e62 to dev.2020-11-05.3.7f8b01a9 (all versions are in this repository). In the newer version, the file
lib/coq/user-contrib/iris/bi/tactics.vodoes not exist any more. However, even after the update, the file exists in my opam switch. Shouldn't opam cleanly remove the files of the old version during the upgrade?(I have not yet tried to reproduce this.)
The text was updated successfully, but these errors were encountered: