I think .rpm/.deb is a bad analogy, since those (a) get installed into a global namespace (the / folder), (b) rely on the existence of other packages in that namespace (their dependencies) and (c) require global consistency between all the installed packages.
You can avoid those global consistency problems by installing RPM/Deb packages into a chroot (or a "proper" container), but that ceases to be a good analogy of what containers are.
Yeah I've spent like a decade building rpms that packaged all their deps inside of them, so I very much don't find the dependency management between them to be fundamental, which might not be intuitively obvious to everyone else.
Maybe it'd be better to call them a tarball, but there is the way that you can install it and run it and then nuke it cleanly which you don't get out of the box with a tarball, which is why I like the package metaphor slightly better.
EDIT: the fact that it is in a chroot, though, I think sort of covers the way that it doesn't really interact with the external filesystem and installed packages. That implies that you have to ship all the deps with the package itself and those usually would be installed into something like /chroot/<whatever> and never into e.g. /usr/bin and the nature of the chroot would make everything in /usr/bin inaccessible. If you build an RPM which installs into a chroot you're really not going to be able to have any dependencies on anything else in the system. The tweaks to make that separation slightly nicer are fairly small tweaks overall. That might not be intuitively obvious though.
> Maybe it'd be better to call them a tarball, but there is the way that you can install it and run it and then nuke it cleanly which you don't get out of the box with a tarball, which is why I like the package metaphor slightly better.
Containers are tarballs, e.g. the rootfs for runc, the layers of an image, and images themselves are usually tarballs. The extra stuff "you don't get out of the box with a tarball" are precisely the tools which we call "containers" (from low-level stuff like runc, to high-level things like online image registries)
You can avoid those global consistency problems by installing RPM/Deb packages into a chroot (or a "proper" container), but that ceases to be a good analogy of what containers are.