cassava/repoctl

Wrong package version detection is leading to catastrophic action. (Current devel)

Closed this issue · 6 comments

I ran repoctl add gtk-theme-elementary-git-5.4.2r113.be9ecef-1-any.pkg.tar.zst to fix a miss-updated pkgver (it was "5.5.2.r5..." before, with an extra dot), and all my 2480 packages were backed up...
This was with c32b18d.

EDIT: The database was kept intact, no packages were removed from it in the process.

The problem is bigger than it seems.

When running repoctl status -m it fails a lot. And then show as if all packages had updates, and their current version is empty.
Log: https://lonewolf.pedrohlc.com/chaotic-aur/makepkglogs/_lab/repoctl.status.-m.logs

EDIT: Downgraded to 0.20, and problems went away...

@PedroHLC I noticed the problem too. Must have introduced a regression somewhere in one of the last commits.

@PedroHLC
This is related to the fix for #52. Previously, when opening a file I would rely on the extension for determining how it was compressed. Some databases didn't have an extension though, despite being compressed. In that case I tried the Gzip compression and if that didn't work, gave up. So the fix for #52 required me to read part of the file to determine which compression format was being used. For all formats, it was possible to only read the header, but for Zst I have to actually start reading data to find out whether it really is compressed with Zst or not. After that I reset the reader and the file, and it turns out that the order with which I do that is important (but not documented, unfortunately).

Anyway, the latest commit should fix this issue. I am sorry about the inconvenience caused!

I'm currently working on improving usage, debugging, and error messages.
So that's going to be coming in the next few commits, and then hopefully everything will be good for a 0.21 release.

Since I had the exact same experience as you, (minus everything being backed up), and was able to resolve the issue as far as I can tell, I'm going to consider this resolved. If that's not the case, just re-open the issue and I'll have another look.

Hey @cassava,

It's indeed fixed in 0.21!
And don't worry, I reverted the issue's consequences quite easily.

Thanks for the tooling and the fast fix!

Glad to be of service! ;-)