FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live compress-build-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync merge-wait multilib-strict network-sandbox news parallel-fetch pid-sandbox pkgdir-index-trusted preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms split-elog strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" acer ~ # ls -l /var/cache/binpkgs/sys-devel/bc total 0 acer ~ # emerge --nodeps --buildpkgonly sys-devel/bc>/dev/null 2>&1 acer ~ # ls -l /var/cache/binpkgs/sys-devel/bc total 132 -rw-r--r-- 1 root root 133120 nov. 26 15:55 bc-1.07.1-r6-1.gpkg.tar acer ~ # tar -tvf /var/cache/binpkgs/sys-devel/bc/bc-1.07.1-r6-1.gpkg.tar -rw-r--r-- 0/0 0 2024-11-26 15:55 bc-1.07.1-r6-1/gpkg-1 -rw-r--r-- 0/0 21536 2024-11-26 15:55 bc-1.07.1-r6-1/metadata.tar.xz -rw-r--r-- 0/0 106080 2024-11-26 15:55 bc-1.07.1-r6-1/image.tar.xz -rw-r--r-- 0/0 885 2024-11-26 15:55 bc-1.07.1-r6-1/Manifest acer ~ # rm /var/cache/binpkgs/sys-devel/bc/* /var/cache/binpkgs/Packages # ack to initial starting point acer ~ # ls -l /var/cache/binpkgs/sys-devel/bc total 0 acer ~ # quickpkg --include-config y sys-devel/bc * Building package for sys-devel/bc-1.07.1-r6 ... [ ok ] * Packages now in '/var/cache/binpkgs': * sys-devel/bc-1.07.1-r6: 130K acer ~ # ls -l /var/cache/binpkgs/sys-devel/bc total 132 -rw-r----- 1 root root 133120 nov. 26 15:57 bc-1.07.1-r6-1.gpkg.tar acer ~ # tar -tvf /var/cache/binpkgs/sys-devel/bc/bc-1.07.1-r6-1.gpkg.tar -rw-r--r-- 0/0 0 2024-11-26 15:57 bc-1.07.1-r6/gpkg-1 -rw-r--r-- 0/0 21904 2024-11-26 15:57 bc-1.07.1-r6/metadata.tar.xz -rw-r--r-- 0/0 105152 2024-11-26 15:57 bc-1.07.1-r6/image.tar.xz -rw-r--r-- 0/0 885 2024-11-26 15:57 bc-1.07.1-r6/Manifest Plz note: Both objects have identical name. However internal root directory name aren't consistent one with another. (bc-1.07.1-r6-1 vs bc-1.07.1-r6) Although it doesn't harm emerge -K sys-devel/bc operability, I can't find no technical evidence why not to bring consistency in this regard. Maybe a one-liner patch, maybe not...
I took a quick peek and this looks like it the relevant variable is the gpkg self.basename attribute which corresponds to the second constructor parameter.
(In reply to Zac Medico from comment #1) > I took a quick peek and this looks like it the relevant variable is the gpkg > self.basename attribute which corresponds to the second constructor > parameter. Ended up in the same area of the code by reading. Too little knowledge prevented me to successfully manage step debugging with the many tools I tried. Hence this report. I would otherwise had a patch proposal.
This little patch seems to do the job: --- a/lib/portage/dbapi/vartree.py +++ b/lib/portage/dbapi/vartree.py @@ -2173,6 +2173,8 @@ class dblink: contents, settings["ROOT"], tar, protect=protect, xattrs=xattrs ) elif binpkg_format == "gpkg": + if "BUILD_ID" in metadata: + cpv += "-" + metadata["BUILD_ID"].decode().strip() gpkg_file = portage.gpkg.gpkg(settings, cpv, output_file) gpkg_file._quickpkg(contents, metadata, settings["ROOT"], protect=protect) else:
Nice quick response. Tested as: * Applying portage-3.0.66.1-webrsync.patch ... [ ok ] * ============================================================================= * Applying user patches from /etc/portage/patches ... * Applying patch.patch ... patching file lib/portage/dbapi/vartree.py patch unexpectedly ends in middle of line Hunk #1 succeeded at 2173 with fuzz 1. [ ok ] * User patches applied. * ============================================================================= >>> Source prepared. However shorten of above test protocol: acer ~ # rm /var/cache/binpkgs/sys-devel/bc/* /var/cache/binpkgs/Packages # ack to initial starting point acer ~ # emerge --nodeps --buildpkgonly sys-devel/bc>/dev/null 2>&1 acer ~ # tar -tvf /var/cache/binpkgs/sys-devel/bc/bc-1.07.1-r6-1.gpkg.tar -rw-r--r-- 0/0 0 2024-11-27 00:36 bc-1.07.1-r6-1/gpkg-1 -rw-r--r-- 0/0 21524 2024-11-27 00:36 bc-1.07.1-r6-1/metadata.tar.xz -rw-r--r-- 0/0 106028 2024-11-27 00:36 bc-1.07.1-r6-1/image.tar.xz -rw-r--r-- 0/0 885 2024-11-27 00:36 bc-1.07.1-r6-1/Manifest acer ~ # rm /var/cache/binpkgs/sys-devel/bc/* /var/cache/binpkgs/Packages # ack to initial starting point acer ~ # quickpkg --include-config y sys-devel/bc * Building package for sys-devel/bc-1.07.1-r6 ... [ ok ] * Packages now in '/var/cache/binpkgs': * sys-devel/bc-1.07.1-r6: 130K acer ~ # tar -tvf /var/cache/binpkgs/sys-devel/bc/bc-1.07.1-r6-1.gpkg.tar -rw-r--r-- 0/0 0 2024-11-27 00:38 bc-1.07.1-r6/gpkg-1 -rw-r--r-- 0/0 21896 2024-11-27 00:38 bc-1.07.1-r6/metadata.tar.xz -rw-r--r-- 0/0 105192 2024-11-27 00:38 bc-1.07.1-r6/image.tar.xz -rw-r--r-- 0/0 885 2024-11-27 00:38 bc-1.07.1-r6/Manifest Shows no apparent changes as bc-1.07.1-r6-1 vs c-1.07.1-r6 remains.
Nothing but my illiterate 2 cents: I'd rather have exoected a change either in quickpkg or elsewhere in emerge source stack depending the side considered as a reference.
Sorry, I've just got aware how your patch focuses quickpkg.
Could be that quickpkg retrieve binary package name (i.e. the indexed filename) rather late in the process: line 237 in quickpkg: binpkg_path = bintree.getname(pkg_info or cpv) I could be wrong but the content of the file seems already defined and set when that line is executed. I keep searchinq where the internal root directory is defined. Maybe another call to bintree.getname elsewhere, maybe not
line 211 in quickpkg metadata = gpkg.gpkg(settings)._generate_metadata_from_dir(dblnk.dbdir) Working debugger confirms metadata has no "BUILD_ID" here...
