This. Distro packaged applications are almost always woefully out of date, because they're frozen before the distro is released, and then you use the stable release of the distro for months or years.

But even if distros adopted some kind of half-rolling-release model so applications could be updated quicker, developers either have to manage N different packaging systems (apt, rpm, etc.) or rely on other people to deal with packaging for different distros, and lose control of a crucial part of their user experience.

Then there's dependencies. Linux distros go to one extreme (no bundling), while the popular approach to developing applications is to bundle most libraries so that you know exactly what version you're working with. There are arguments for both approaches, but it's another source of friction between developers and distros.

Distro packaging works for computational infrastructure that's widely used and not changing much, but it's a poor fit for what users and developers expect for actively developed end-user applications.

Shameless gentoo plug: gentoo does rolling releases. There's still stable v unstable but it's per-package. I've run everything unstable for years (except the kernel and default gcc which I update only infrequently). Most packages get updated unstable ebuilds within days of release, probably because with nice upstream choices, a new ebuild can be made with a change on a single line. I've even made such an ebuild myself with no experience when I needed today's version.

There's even a way to make an ebuild for nightlies, although you can get build breaks with those.

People making distos, as well as anyone who has been bitten by unreproducible binaries generated by hand-crafted/manually driven build processes.

When I install software from a distro, it's been vetted and I can safely assume the software has a sane reproducible build process, or at a minimum, has had a sane reproducible build process added by the package maintainer.

If a new standard wants to solve that process, I'm all for it, but I demand reproducibility (or somebody to hold financially reaponsible, in the case of closed source)in my software builds.

Nobody except weird Linux nerds and developers cares about any of the things you listed.

Normal people just want to click a link and have their app install and run.

I don't why you are been down voted. Normal people would to download the s/w , install and run. As a developer sometimes i wish the same as well instead of hunting down dependencies.

Yes but the logical extension of that argument is that people don't care about food-safety because they don't know what e-coli is.

And that is true.

So, the problem is not package managers per se, but the velocity of updates? Fix that instead? (see Arch Linux).

What if I prefer a predictable release cycle for the base OS, but still need the latest LibreOffice/VLC/_____ for one reason or another?

I like the approach taken by e.g. Nginx and MariaDB, where I add additional vendor repositories, but this workflow is probably neither user-friendly enough for my mom, nor have all vendors the resources to maintain several repositories for different distributions and their respective versions.

Use an OS with backports, like Debian. For example, if you took Debian Jessie, you could pull LibreOffice 5 from backports. VLC is already almost up-to-date (2.2.1).

That's one use case. Here's another: I am a user who wants stable secure software above all else. When faced with the need for a version of software that is not yet provided by the distribution, I download, verify, build, and test the software from source.

The "every application gets the same release cadence no matter what" approach appeals to me, and I'm a normal user.

Nothing in using the distro's packaging formats forces you to release only at the same time as the distro.

While of course you are technically correct, think about it from the grandma perspective. Grandma uses $app that requires wine, but grandson set her up on Debian stable. She can't run the latest wine because it isn't stable, and it's needed for $app, without updating the system to unstable.

I could be erroneously attributing the intended use case, but I believe this isn't designed for people who know what they're doing; it's for people who don't know, like grandma.

I have some programs that it's ok if they are bleeding edge and unstable to get the most features. Some programs that is not ok. And if those 2 categories have a shared dependency (different versions of it), that becomes an issue.

I would say that most things should use the old model, but there are scenarios where this could be preferred.

Then use one of the many available PPAs? If the package is so unique that no one maintains a PPA, then chances are that no one maintains an AppImage either. In that case, build from source. (Pro tip: when building from source, install using GNU stow so you can easily uninstall as well.)

But as a developer you don't want to build a gazillion of packages to be able to reach many users.

Building from source? Please try to imagine this from the point of view of users who aren't so technically expert as you are. They just want to, for example, run the latest version of VLC.

Yes this is a challenge for developers. I don't think the answer is yet another package format.

I may be wrong, but isn't Ubuntu/Canonical "snappy" supposed to solve this problem?

https://developer.ubuntu.com/en/snappy/