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
