On 01.07.24 11:13, George at Clug wrote:
As a general rule I am willing to accept RPMs, pacman ?? packages, and .debs,
when they are from the Distribution's own package libraries, or hardware vendor
supported,
Hardware vendor distributed installation files usually should not be used,
especially not over the distributions packages and especially not when it comes
to GPUs. Nvidias own drivers are infamous for having terrible installers. If
you need them, install them the way your distro recommends. So if you'd install
hardware vendor packages but not other third party packages, you should really
think about your decisions, as they don't make any sense.
I have this strange belief that when a developer supplies a package to the
Distribution owner for inclusion in their libraries
At least not how Debian works. As the package's developer, nobody would stop
you from being the maintainer of the Debian package in the official repo, but
in general everybody can step up for that job. So a package being in Debian's
repos is no guarantee for anything, especially not if not maintained by the
core developers. But of course, maintainers need to stick to a rule book too,
if they don't, their maintainer status will be revoked and their packages
removed. Also, that's why to use Flatpaks and not just some random .debs -
including the ones from hardware vendors not really giving a fuck. With
Flatpaks, you can easily see if it's maintained by the developer or not. Also,
they are isolated and have quite user-friendly permission management. Of course
no software is bug-free, but it's better than nothing. Especially when you
compare Flatpaks with Debian contrib or non-free packages.
, the Distribution owner does some level of verification/validation that the
package plays nicely with the distribution and other applications. Maybe even
some security checking?
I wonder if anyone agrees with me, or not?
Good question, how far Debian goes here. The automated testing will most likely
catch the biggest issues, but then that's irrelevant with universal formats
like AppImage, Snap and Flatpak, as they don't really interact with other
packages. And especially during the 6 months of feature freezes before a
release, users on testing can very well tell how well all the packages work
together and report bugs so worst case a package causing issues can be replaced
by an older version that works better. Then again, that's irrelevant with
universal packages too.
Now the security part is a good question. It's well known that Debian developers try to fix any security issues as fast as possible, especially in Stable, even doing backports themselves if needed. But I have no idea how far Debian goes with preliminary security checks, before packages reach stable. Also, due to Debian enforcing some sanity on packages, everything that should be a dependency in its own package will be made into one, no matter what the developer wants. And only having to patch one package to fix a security issue in many - think issues in OpenSSL and the likes - is always better than having to patch every single package using it. That's the great benefit of Debian over e.g. Flatpak, though Flatpak does move the most common dependencies into runtimes to achieve something similar. But it won't enforce this. But on the other hand, being containerized does decrease the need for some patches as the security issue may just be much more difficult to abuse, as an
attacker would not only have to exploit it but also have to break out of the container. So it's all quite relative.
There seems to be way too many methods of packaging these days.
That's why AppImages, Snaps and Flatpaks where invented, it's just way too
difficult to support them all. And with sane default behavior and
containerization, Flatpak is by far the best of the universal formats.
I also think there are way too many distributions of Linux too, but if people
have the time, I should not rail against them. I prefer to stay with as close
to the original source distribution as possible, though I have yet to apply
this to compiling from Gentoo Linux.
That's freedom - especially of choice - for you. But beyond the big distros,
you should only touch the myriad of distros when you know what you are doing.
