>>4788
>The build systems are broken, packing could be an extension of the build system.
>cmake, premake, meson, scons, waf, et. al are nothing more than bloated reimplemtations of autotools.
This hits the nail right on the head imo. Packaging should be as easy as clicking a fucking button, yet it isn't.
This is because of various factors, such as there not being a format to specify metadata (package description, tags, etc) until very recently (appinfo.xml), and build systems not forcing users to make their software compatible with distro packaging standards.
I regularly package software for gentoo, and most of the time is spent fixing broken build systems and software. Either because they hardcoded paths, install shit in wrong locations, hardcoded utilities and CFLAGS, made it impossible to cross compile, modify data in /usr/share/.mono or /usr/share/myshitapp on runtime, don't have a way to select whether a dependency is enabled or disabled (instead querying pkg-config and relying on its results), is bundling some shitlib without an option to unbundle it, is downloading shit from the internet resulting in inconsistent builds, doesn't build correctly with the latest compiler, or is using some language/framework that breaks any of the former (e.g. the cancer that are rust and go requiring you to use their package managers).
All of these issues have been solved in various ways in various build systems for ages, but software developers are never taught how to use them correctly. A well-behaved autotools project requires only three lines worth of a script for packaging, a well-behaved cmake project only needs an extra "inherit cmake" to be packaged. Instead, I'm spending most of my time patching your broken cmake files because you decided to fucking call "make" on a submodule despite CMAKE_GENERATOR being set to "Ninja", instead of using whatever mechanisms cmake has for this shit, or you're installing a submodule's shared library that's already available system-wide, causing who knows how many headaches, because it happens to honor -DCMAKE_BUILD_SHARED=ON, even though the rest of your project doesn't.
The only build system I've yet to have any headaches with is meson. "inherit meson" has never fucking failed me, and I wish more people used it. It actually does bundled libraries properly, allowing distros to just unbundle them easily, and upstream devs to be happy that their libraries are statically linked.
The only thing other than a good build system that we need, is a distro-agnostic method of specifying dependencies. Solus OS has the right idea on this, using "(bin)command-name", "(pkgconfig)library-name" or even "(python)library-name" as dependency specifications, since the names that shit is actually called programming-language wise are distro-agnostic, and their packages export a "provides" field, so the requirements can always be found regardless of how the packages are split up or named in the distro. You could probably generate a good chunk of these "provides" on a cross-distro basis by just scanning their package file listings, and make a tool to convert these dependency specifications to actual package names.
And with all of this, you essentially now have a system where a well-behaved dev just presses a fucking button and gets well-behaved and compliant package build scripts for 20 distros. Add some docker magic and you would even get the binaries and publish the repos.
But of course, all of this is wishful thinking. There's still library compatibility issues (what if a dev wants to statically link a slightly newer library? need toggles for this now... also rebuilds on rolling distros), and the tool would get hopelessly complex.
Flatpak is the easier solution -- just shove packaging standards and compatibility out of the window, give the dev a sandbox to fuck up anything in, and don't let them touch the system.
I don't mind flatpak's existence, but I do believe it's a broken remedy for a broken system, and it makes software devs even more greedy about their compliance. Attempting to package flatpak apps is sometimes an exercise in insanity, since devs are increasingly relying on bleeding edge libraries and specific commits of them, and sometimes those libraries just can't be statically linked.
My biggest hope right now is that flatpak simply becomes an option for the impatient or specific needs that distros just can't package, and distro packages continue to thrive with stable, even if a bit outdated, and well-integrated software. The main reason I use gentoo is because it makes it piss easy for me to patch out deficiencies in software (and not have to do it for every release) -- flatpak and every language enforcing static linking (npm, go, rust, dotnet, ...) are the antithesis to this.
I fear that instead it will become a vehicle for devs to be lazy and care about distro packaging even less than they have been at this point. Talking to some devs about the virtues of dynamic linking and working together with packagers to ensure they can integrate it with a distro properly (and the packagers can help them do QA, they're always the first testers) and take care of bugs/exploits in libraries, reveals to me that most of them only care about their software, not collaborating to an operating system's ecosystem. They all want their little island, they all want to be incompatible with everything, and flatpak is perfect for that.