On Wed, Nov 21, 2018 at 11:45:54AM +0100, Fabian Groffen wrote: > We agree it is hackish, and we agree we can do without. You simply > exaggerate the problem, IMO, which mostly isn't there, because it works > fine today. It can also be solved today using shell tools.
I am sad that you don't see it as a productivity impediment that the user is required to know the custom tooling to do even such a trivial non-standard action as manual extraction. Maybe I will make myself look bad by admitting this, but I'm not meeting your expectations. I use Gentoo for ~11 years, and for about one year I am using my private binpkgs distributed to all my machines (i.e. I have read binary package guide fair number of times, but I stopped rereading it when I satisfied my needs). When in need, I still reached to trusty tar, and I did not even know what are the names of special tools (a toolchain?) qtbz2 and qxpak. Just few days ago I messed with binpkgs for investigation purpose. I just wanted to extract few to somewhere (definitely not into system root), and read a core dump with GDB asking it to use those extracted files for debug symbols. Of course I used `tar xaf`, because what I know is that it's honest tbz2 just with metadata appended. # tar xaf boost-1.65.0.tbz2 bzip2: (stdin): trailing garbage after EOF ignored Exit code is 0. But the notice is annoying (on subconscious level), because Silence Is Golden - "when a program has nothing interesting or surprising to say, it should shut up". > % head -c `grep -abo 'XPAKPACK' > $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | sed 's/:.*$//'` > $EPREFIX/usr/portage/packages/sys-apps/sed-4.5.tbz2 | tar -jxf - > > results in no warnings/errors from bzip about trailing garbage, possible > thanks to the spec being smart enough about this. Thanks, this is a very concise **custom tool** to handle current binpkg format. > Not having to do this, when under stress and pressure to restore a > system to get it back into production, is a plus. Though, in that > scenario the trailing garbage warning wouldn't have been that bad > either. When understress and pressure, the irrelevant warning is not bad? I am sure it is really bad for operator's attention.
signature.asc
Description: Digital signature