What is off the table, exactly? You asked why you would extract a deb instead of extracting a tarball or curl|bash, right?

Because the deb is verifiable, because the deb can be inspected, because the deb is versioned, because the deb can be bug-reported, because the deb has dependency info, because you know what the deb was built for and supports, because the deb has clear scripts which tell you how to install and uninstall it, because it can be unpacked offline, etc.

Maybe you don't care about any of this. That is fine. I'm just telling you what the Deb gives you that a tarball or curl|bash won't.

* Just about every .tgz I've ever downloaded had instructions on the downloading page to verify its signature

* I can inspect a .tgz easier than a .deb (tar -tzf)

* More often than not, the tgz version is in its filename (foobar.1.3.0-24.amd64.tgz)

* With that info, I can bug report it

* Fair 'nuff on depdencies

* I know what the tgz was built for and supports by either the download page or the filename

* Just about every tgz package I've ever downloaded included a Makefile that handled installation and uninstallation

* Offline unpacking is the only way to handle tgz's

Literally the only benefit to offline unpacking a .deb vs offline unpacking a .tgz is that the former includes a CONTROL file that lists dependencies in it.

So we both agree that RPM is superior to all these methods, and that curl|bash is effectively not even worth talking about; great. It seems the question you're posing is: why would I use a deb when I could just make a Slackware package (which is what you're using as an example of a 'tarball', which is actually just another name for a tar file, but I digress) and 'unpack' that.

As you must be aware, both Slackware and Debian have methods to install a package locally: 'dpkg -x package.deb $HOME/` for Debian, and 'installpkg --root=$HOME/ package.tgz` for Slackware. This is effectively an easier way to 'unpack' the packaged files without performing any other operations.

You mention verifying signatures? That's built into the deb. It isn't built into the tgz.

You mention 'inspecting' the deb is more difficult. Yet 'dpkg -c package.deb` is not only less characters to type, it gives you more detail due to the nature of the deb's file layout.

You mention the version is in the tgz file name 'more often than not'. Doesn't really give me the warm and fuzzies compared to having a file with real metadata about the origin of the package, like deb provides.

And a random version number does not give you the info to report a bug. If it's not official, you have no idea who built it, unless the author added their e-mail to a file inside the package, which most don't. And even with the version and author, you still don't know what system the package was built for! If you're lucky the version was bumped from one distro version to the next, and with luck they never built the same version for more than one distro version!

HOW do you know what the tgz was built for? Sometimes the architecture is included, but you don't know what distro, what version, or any other platform or build-specific information. A 'download page' is not reliable metadata, nor is it included with the package, thus the package does not have the information, thus it is irrelevant to this conversation.

Slackware packages do not come with Makefiles for installation nor uninstallation. In fact, almost no precompiled tarball i've ever seen has had a Makefile for installation or uninstallation. And i've manually packaged well over 10,000 pieces of software for various distributions.

Comparing Slackware packages and debs is like comparing a bicycle to a Ford F-150. Sure, the bicycle is lightweight and easy to use. But a pickup truck is way more useful.