|
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. 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.There seems to be way too many methods of packaging these days. 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.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. |