I just found this file /var/cache/binpkgs/media-fonts/pothana2k-2006-r1.tbz2 /var/cache/binpkgs/media-fonts/pothana2k-2006-r1.tbz2: XZ compressed data
Created attachment 591626 [details] info emerge --info
I think probably what we should do is make the FEATURES=binpkg-multi-instance layout default, so that all file name end with .xpak regardless of compression type.
hmmm, isn't .xpak the name of just the vdb metadata archive?
(In reply to Fabian Groffen from comment #3) > hmmm, isn't .xpak the name of just the vdb metadata archive? Well, xpak is the name of the format used for the vdb metadata archive, but also .xpak is the file name extension used for tbz2/txz/tgz/tzst files that you get with FEATURES=binpkg-multi-instance enabled. Including the compression type in the file name extension is not very convenient, so we simply probe the compression type from the file header.
Ok, what I meant is (this is portage-utils speaking), xpak is the trailing part of the file, not compressed at all, because it's just a postfix to the actual data. qpkg/qtbz2/qxpak allow splitting and joining a file of any kind with an xpak file, the latter that can be read much like an ar-archive by qxpak. Similar to how quickpkg generates such file. Now qtbz2 probes the file much like Portage does, so whatever the name is doesn't matter, but using .xpak would cause some confusion here. It historically emits tar.bz2 and .xpak files to differentiate between the two bits in the file. Isn't there a better approach of calling it .ebinpkg or something? I don't recall what Michal's proposal had for binpkg's v2 but in any case it should be different from that.
In the implementation of bug 150031 we went with the .xpak extension, and changing the extension once again doesn't seem very appealing. We haven't had any complaints about the .xpak extension during the past few years. In https://www.gentoo.org/glep/glep-0078.html, it suggests .gpkg.tar as the file extension for the new format that it proposes.
The format is recognized by sys-apps/file since last year (added in https://github.com/file/file/pull/47). The file extension has nothing do with the definition. It's defined like this: diff --git a/magic/Magdir/archive b/magic/Magdir/archive index f8cf3a268..ac3944c77 100644 --- a/magic/Magdir/archive +++ b/magic/Magdir/archive @@ -1427,3 +1427,9 @@ # LyNX archive 56 string USE\040LYNX\040TO\040DISSOLVE\040THIS\040FILE LyNX archive + +# Gentoo XPAK binary package +# by Michał Górny <mgorny@gentoo.org> +# https://gitweb.gentoo.org/proj/portage.git/tree/man/xpak.5 +-4 string STOP +>-16 string XPAKSTOP Gentoo binary package (XPAK)
Given we have gpkg now, I feel like this is obsolete. We also made binpkg-multi-instance on by default anyway.
*** Bug 823353 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=e799003581e49a3ba2aac0d49821f52ed6eda931 commit e799003581e49a3ba2aac0d49821f52ed6eda931 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-14 04:57:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-12-14 05:03:15 +0000 man/make.conf.5: describe binpkg suffix - BINPKG_FORMAT="xpak" has suffix .tbz2 for any compression type(!) - BINPKG_FORMAT="xpak" and FEATURES="binpkg-multi-instance" (default as of bug #715112) has suffix .xpak. - BINPKG_FORMAT="gpkg" has suffix .gpkg. Bug: https://bugs.gentoo.org/696080 Bug: https://bugs.gentoo.org/715112 Bug: https://bugs.gentoo.org/721070 Bug: https://bugs.gentoo.org/885799 Signed-off-by: Sam James <sam@gentoo.org> NEWS | 3 +++ man/make.conf.5 | 10 +++++++--- 2 files changed, 10 insertions(+), 3 deletions(-)
