Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#62284 - [repo-add] db corrupt after repo-add of existing version
Attached to Project:
Pacman
Opened by Stephan S (buzo) - Tuesday, 09 April 2019, 10:26 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 14 April 2019, 08:05 GMT
Opened by Stephan S (buzo) - Tuesday, 09 April 2019, 10:26 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 14 April 2019, 08:05 GMT
|
DetailsSometimes I need to rebuild one AUR package because of updated dependencies, but obviously the version of that AUR package does not change then.
After building, I run «sudo repo-add custom.db.tar.xz mypackage-x86_64.pkg.tar.xz» as usual to update my repository with the newly built version. But this works only if that package was not in the repository before, or with a different version. Trying a «sudo pacman -S mypackage» later results in: :: File /var/cache/pacman/pkg/mypackage-5.12.2-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (checksum)). Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package) Errors occurred, no packages were upgraded. Workaround: «sudo repo-remove custom.db.tar.xz mypackage» before «repo-add» Additional info: * pacman 5.1.3-1 |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Sunday, 14 April 2019, 08:05 GMT
Reason for closing: Not a bug
Additional comments about closing: User error due to cache confusion.
Sunday, 14 April 2019, 08:05 GMT
Reason for closing: Not a bug
Additional comments about closing: User error due to cache confusion.
Can you post the output of the second repo add invocation. Also, extract the repo before and after and post the desc file for the package.
pacman is stating that the cached package in /var/cache/pacman/pkg is corrupt, which is absolutely true (and is required to be true) if you've previously downloaded and installed the package. And since you're using a custom repo, pacman *will* download the package, even if the download handler is the file:/// protocol which uses speedy direct filesystem access rather than hitting up the network. It is possible to circumvent this entirely, by specifying the same "Server = file:///..."; directory as a CacheDir as well... but you haven't stated you've done so.
I could theorize that your repo-remove occurred after you failed to pacman -S, and then after, you tried pacman -S again and it worked, but the actual fix was selecting "Y" (the default answer) when faced with the prompt:
Do you want to delete it? [Y/n]
Please confirm if this was the case. And if you can still reproduce the problem, please do as Allan said and post the files involved, along with complete logs of everything you did (including pacman), so we can try to reproduce it too.
> Sometimes I need to rebuild one AUR package because of updated dependencies, but obviously the version of that AUR package does not change then.
This is absolutely wrong, and you (rhet.) should bump the pkgrel to ensure it registers as an update, with a new package file, rather than a reinstall but with a potentially corrupted cache.
If the AUR maintainer does not bump the pkgrel, you can bump it yourself by adding a .1 to the end, e.g. mypackage-5.12.2-1 becomes mypackage-5.12.2-1.1, then mypackage-5.12.2-1.2, etc. and if the AUR maintainer bumps it, they will bump it to mypackage-5.12.2-2 which will register as an update because 2 > 1.1 > 1 and at this point you simply revert back to the AUR pkgrel without local modifications.
Doing it this way makes life much simpler, and you'll never become confused about which rebuild you have installed.
I did not know this and neither have I found such an advice in the Wiki yet. So no problem – I'll bump the pkgrel of the AUR packages maintained by me in the future.
No, I have not, since I did not know about this yet.
> Do you want to delete it? [Y/n]
Actually, I did not answer this question myself, since this «pacman -S» was run automatically inside «makechrootpkg -cnur /opt/chroot -D /etc/pacman.d/local». So I don't know which answer was taken.
See attachments.
> I could theorize that your repo-remove occurred after you failed to pacman -S, and then after, you tried pacman -S again and it worked, but the actual fix was selecting "Y" (the default answer) when faced with the prompt:
Right, it works on the second try … I did not notice that before.
Since you're using makechrootpkg, --noconfirm is in play, and the default pacman action (selected by --noconfirm) is to delete the cached package and try again. The second time around, it redownloaded the file from your (local) repository -- which is the second file, that you overwrote with cp, so that worked fine once the stale cached file was removed.
Using a shared cache would mean that the first time, pacman would look for the file in the /etc/pacman.d/local/ cachedir, find only the overwritten file, and try to use that, which would work as it matched the database. (Note that in this case, pacman -Scc runs the risk of deleting files which you did not intend to remove. But I generally consider this a worthwhile tradeoff, and use paccache instead.)
Using a .1 incremented pkgrel would mean it always looks for a different named file and sidesteps cache issues automatically.
Feel free to enhance the documentation on local repository workflows with my advice, wherever you may think it is suitable. :) For now, since it appears that your problem is solved, I will close this bug report.