I always felt like snappy/flatpak/appimage were stupid ideas, but didn't exactly know why.
Then someone wrote this article
http://kmkeen.com/maintainers-matter/
and suddenly it all makes sense.
@Wolf480pl
I'm generally anti-maintainer, but I can see from this how maintainers are probably desirable for making an environment where beginners who can't vet their own source code aren't taken advantage of.
I still think it's probably a waste of time for someone who knows how to code & how to build packages to use a maintained distro, on the grounds that such people have strong opinions about how software is packaged that differs from distro maintainers.
@enkiv2 Right now I have 900 package sinstalled on my Arch laptop.
I can't imagine how I could possibly review each of them for quality and malice, figure out the build flags, and then keep track of the updates.
Also, most of my strong opinions align with those of Arch maintainers. Some don't. But I don't mind. For me it has the best cost/benefit ratio I've seen so far.
@Wolf480pl I've had a basically poor experience with Arch, because Arch maintainers have major philosophical differences with me. Likewise, Debian (though Debian's package management renders my system unusable less often than Arch's). I prefer Lunar, on the grounds that Lunar is more hands-off: maintainers tell the package system about dependencies but do not write patches (and really are just approving user submissions of package info)
@enkiv2 Arch also has a very strict policy against patching. Most of the time they only set ./configure options, and sometimes patch in a missing DESTDIR to the makefile, because duh, you need to make install into the dir that will be tar.gz-ed and not into filesystem root...
@Wolf480pl In the case of Lunar, the policy is: we do not patch files at all, nor do we take bug reports for packages other than the package manager, nor do we host any files ourselves (though we may mirror third-party patches submitted to us or mirror extremely important packages that are part of the base image of an installer), nor do we support binary packages at all (with the exception of the installer livecd).
@enkiv2 @Wolf480pl
>we do not patch files at all
what about bugs to fix serious compatibility problems in software?
@Wolf480pl @a_breakin_glass Upstream's problem. Any package that is not compatible with any other package is broken.
@enkiv2 @a_breakin_glass
good luck being compatible with openssl 1.0.x and 1.1.x at the same time.
@Wolf480pl @a_breakin_glass
Why would I need to be? I rebuild any dependent package if I upgrade a minor version & I have separate packages for major versions in the case that both need to be installed simultaneously.
No distro maintainer is going to be more capable of reliably writing significant code changes to a third-party project than the project maintainer. If I care enough about a version bump, I can write those changes myself & submit an upstream patch.
@enkiv2 @a_breakin_glass
Well unless you resort to #ifdefs, but you get the idea.
@enkiv2 @a_breakin_glass
I was responding to:
>Any package that is not compatible with any other package is broken.
And my point is that there are pairs of packages (X, Y), such that no package that uses X can be compatible with Y, and vice versa.