Linux package manager tools care about the individual files installed so that un-install operations remove them correctly. This is true of Red Hat and Ubuntu as well, just with different tools (rpm, deb, yum, synaptic, portage, packagekit, etc). All of these tools track what specific files are installed by each package in a local database. Files created “on the run” don’t end up in the database, and are therefore retained when un-installing. This is deliberate on the package managers’ part, as they want to preserve data files when upgrading packages from one version to another.
Obviously, this is precisely the opposite approach from Microsoft Windows, which expects application developers to supply uninstall tools to go with their apps. Linux distributors don’t trust app developers to do this properly in the face of the wide variety of targets, so they handle it themselves.
So, for standard linux distributions to properly uninstall or upgrade ignition using their native package managers, the package installation process must expand its distribution archives to the form needed at runtime. Java JARs don’t need to be expanded, because java uses them as-is.
You have JARs inside the .gpkg, though (among other things). At first run, they are placed appropriately in the contexts folder. Later, when the native package manager is told to un-install, the contexts folder will be left in place, under the presumption that these are data files, not executables and static resources. When the next version is installed, it won’t necessarily overwrite the previous context, unless your runtime is smart enough to verify the contexts folder contents against the versions folder every time the service starts.
The database of installed files typically includes SHA1 or MD5 hashes of every file installed, specifically to identify “initial copies” of app data files that shouldn’t be removed on un-install. (Also used to notice customizations in the /etc folder, to avoid overwriting them on upgrade).
In any case, I’m willing to help prepare the Ubuntu/Debian .deb and Red Hat/CentOS .rpm files after this is all sorted out. By the way, those formats are archives themselves, so they’ll need to include everything you now include in your .tar.bz2 files. In contrast, Gentoo ebuilds only have scripts and metafiles… the install process uses info in the scripts to go fetch the necessary archives on demand.