I didn’t propose any alternatives, you’re right – to be honest, I’m not really sure what the alternative ought to look like. I think we need to start from first principles, though, and work from the basis of what best meets the needs of the users.

I think the security aspect is interesting, because it’s the most obvious “the perfect is the enemy of the good” problem that Fedora has with package management. Yes, unbundled libraries make it really easy to issue security updates. However, 80% of the users (we can argue the actual figures, hopefully we can agree it’s probably a majority) aren’t receiving security updates! So, if we really care about security, we should prefer to make the distribution as easily upgradable from release to release as possible – and if that’s at the cost of unbundled libraries, then as far as I’m concerned, so be it (however, I don’t think the two are incompatible).

So, for example, you cite the ABI/API churn and bundling as two critical problems. But they’re only problems because of the way package management works in Fedora. We look down on bundling because it bloats memory and makes it more difficult to issue security fixes. In the grand scheme of things, though, another few meg of library data makes very little difference to most people (the runtime working set of such software is much greater than the code they use), and the security fixes argument is a little bit trite when 80% of users aren’t receiving them.

As you say, it would be perfectly possible to distribute an RPM of chromium – it’s just that policy-wise, Fedora chooses not to. This isn’t a technical issue, but this is precisely the issue I’m pointing out!

Interesting idea about package management having had its day. There are certainly plenty of modern applications that don’t easily fit into the package management paradigm, particularly web and javascript apps, as you’ve said.

What sort of alternatives would you suggest?

Also, the biggest reason I like unbundled libraries / package management is the security aspect. How would your alternatives address this?

* upstream moving incredibly quickly, with no regard for ABI/API
* upstream bundling everything they come across, then forking the items that they bundle

If you go to the Fedora homepage, it says “Fedora is a fast, stable, and powerful operating system” – and at the moment, it’s not living up to that. There are something like 33 million IP addresses that collect Fedora updates, implying something close to that number of installs.

Are you really claiming that “bleeding edge, occasional breakage, but that’s fine” attitude is representative of those 33 million-odd users?

I would rather suspect that it is entirely a minority view.

I use Fedora especially because it is bleeding edge. This is what Fedora is known for and what makes it unique. Being on the tip of free software development has advantages for me. For this, I’m ready to put up with occasional breakage.

If maintaining older Fedora releases means less manpower for making advancements, then as far as I’m concerned, drop those releases.

The nice thing is, we have numerous fine distributions available. On some boxes I actually use Debian because I think its a better fit for those. There’s no reason why a single distribution has to cater to all kinds of users for all possible fields of use. Fedora once was known for delivering new software versions not only on new releases but also as updates without the need for running a whole rolling release distribution. The new update policy kind of killed that “unique selling point”.

In my opinion the restrictions on pushing updates actually make the situation worse for users. Fixes to real problems don’t get pushed in time, therefore exposing users to known bugs for a longer period of time. Heck, even critical security updates don’t get the neccessary testing and are delayed, sometimes even for weeks. What could be possibly worse than being vulnerable to remote exploitation? This is just bad and needs to be fixed.

As long as there is no solution to those problems, yes, it seems as the update policy just gets in the ways of maintainers trying to fix actual problems that users care of.

I don’t think you can assert that it shouldn’t be allowed in Rawhide. You don’t know the background and you didn’t really ask either so I am not going to bore you down with the details.