I ^C quite often apparently and often end up with noise like this: ``` >>> Jobs: 0 of 3 complete, 3 running Load avg: 0.24, 0.09, 0.52Error reading binpkg '/var/cache/binpkgs/dev-util/pkgcheck/pkgcheck-0.10.23-1.gpkg.tar': [Errno 22] Invalid argument!!! Invalid binary package: '/var/cache/binpkgs/dev-util/pkgcheck/pkgcheck-0.10.23-1.gpkg.tar', Error reading binpkg '/var/cache/binpkgs/dev-util/pkgcheck/pkgcheck-0.10.23-1.gpkg.tar': [Errno 22] Invalid argument Error reading binpkg '/var/cache/binpkgs/dev-util/pkgcheck/pkgcheck-0.10.23-1.gpkg.tar': [Errno 22] Invalid argument!!! Invalid binary package: '/var/cache/binpkgs/dev-util/pkgcheck/pkgcheck-0.10.23-1.gpkg.tar', Error reading binpkg '/var/cache/binpkgs/dev-util/pkgcheck/pkgcheck-0.10.23-1.gpkg.tar': [Errno 22] Invalid argument ``` The output is pretty ugly so we should fix that, but the main issue is that these invalid binpkgs are left behind. I think what happens is: 1. Emerge starts 2. Install completes and Portage starts to create a binpkg (possibly invoking a slow compressor) at the *real* path like /var/cache/binpkgs/app-misc/foo/foo-1.gpkg.tar (no temporary suffix) 3. Interruption during this process leads to a broken binpkg being left at the real path We should instead write to a .tmp or .partial then rename once the process is complete (even just the compressor is likely enough).
Note that I didn't heavily use xpak but use gpkg now, and I suspect it might be more likely with gpkg..?
That file maybe a placeholder, the temporary files should already had a suffix when creating. Or it get interrupted in the post-process.
(In reply to Sheng Yu from comment #2) > That file maybe a placeholder, the temporary files should already had a > suffix when creating. Or it get interrupted in the post-process. Ah, I see. Yeah, placeholder or interrupted makes sense. It's 0 bytes for me.
I run into a similar issue that (probably) has the same root cause. While emerging a package I got Error reading binpkg '/var/cache/binpkgs/net-im/profanity/profanity-0.14.0-r1-1.gpkg.tar': [Errno 22] Invalid argument while profanity got simultaneously emerged. So it appears that portages creates the binpkgs in PKGDIR. Instead, portage should use a temp dir when creating binpkgs and once finished, move the result into PKGDIR. Or, if portage got interrupted, the tempdir should be deleted. This would probably fix the original misbehavior reported in this bug and what I experienced.
I caught this at perhaps a better point today: -rw-r--r-- 1 root root 0 Sep 28 14:34 gcc-12.3.1_p20230922-3.gpkg.tar -rw-r--r-- 1 root root 39K Sep 28 14:34 gcc-12.3.1_p20230922-3.gpkg.tar.688064 We do create a placeholder and we put the gunk in there while we're compresssing ... but we *also* create a placeholder at the real filename!
I thinks this summarizes the issue: The gpkg format requires we create a directory matching the name of the package file. For example, baselayout-2.14-4.gpkg.tar must contain a directory named baselayout-2.14-4. To avoid race conditions with multiple Portage processes writing to PKGDIR, we need to "claim" a package file name before actually writing to it. We claim the package file name by creating an empty file in PKGDIR. That empty file is what produces the "invalid binary package". I think the only workable solution here is to ensure we remove the empty file when errors occur or when we get interrupted by a signal.
> I think the only workable solution here is to ensure we remove the empty file when errors occur or when we get interrupted by a signal. Or possibly we could switch to using some other file pattern or locking mechanism to claim/reserve a package filename while the package is being created.
