Hacker News Reader

Comment by kelnos | Hacker News Reader

I usually try not to be blatantly negative, but this is just stupid. Most users do not care how quickly new versions of software get to them. The current distro packaging system is just fine. Leave it to Poettering to come up with something complicated for no good reason.

The funniest part is that he's using systemd as an example. That's exactly the kind of software that I want to change very rarely, and I want those changes to be vetted and integrated by someone intimately familiar with the distro I'm running. The idea that I'd run an upstream-packaged version of something like systemd is absurd.

The proposed packaging system is just another system incompatible with all the others out there.

Want a standardized system image? Build one from your distro of choice (guess what: your users don't care about that either), uninstall dpkg/rpm/whatever, make a disk image. Automate the process so it's reproducible. Done.

View on HN

>Most users do not care how quickly new versions of software get to them.

Users do indeed care about getting bugfixes and new features in a timely manner.

I'm not sure if this is the solution to that problem, but it would be good to have a way to make pushing packages downstream easier - decoupling the configuration/integration, testing and security code review steps.

This is a problem that the distros themselves need to fix, though, not Poettering.

Sadly, this is only true if they are affected by the bugfixes. And, honestly, most users need to be taught to avoid upgrades that include massive feature creep that actually has the potential to pose security and stability problems.

The current packaging systems has problems. You cannot install just any version of any application on your system, but a lot of people want that.

A nice example is games. You want to install a game on your system without working around the package manager. That was very hard to do if you weren't on the distro that the game was build for. For instance, if the game was just released, there was little chance it would work on Debian stable...

Steam has solved this problem by using their own package manager and their own set of 'approved' libraries that other games must link to. Steam always ships with the set of 'approved' libraries, just so that it can side-step the libraries on your system.

The same is true if you want to build a piece of software that seems to be incompatible with your system: it needs a different GCC, it might need a different version of Gnome libraries.

Also, disk images aren't as simple as you make it seem. If you have a system and want to upgrade one of your applications (but leave the rest as they are!), you aren't going to like the current package management tools.

These kinds of problems happen often for a lot of people and a solution is highly appreciated. That said, the solution in the article probably isn't the best.

> You cannot install just any version of any application on your system, but a lot of people want that.

That's the price of shared libraries (which you're trading off for easy security updates).

If you don't like this, you're still free to run statically-linked programs.

> Steam has solved this problem by using their own package manager and their own set of 'approved' libraries that other games must link to. Steam always ships with the set of 'approved' libraries, just so that it can side-step the libraries on your system.

So it's OK for Steam to do this, but not the OS vendor? I don't follow your logic.

This could have been solved on a different level. If the right architecture was in place Steam didn't need to solve it.

You can have multiple shared libraries of the same name, but different major versions. Applications that need the same version can use that same version. Applications that need different versions can use different versions. The package repository shouldn't be the conflicting factor.

Most distributions have provisions for installing multiple major versions of a shared library (they change the package name to libfooX to accommodate this).

You cannot install just any version of any application on your system, but a lot of people want that.

My thesis is that no, a lot of people don't want that. Who are we talking about here? The "self compile from source tarball" crowd grows smaller and smaller. The kind of user that is going to want a pre-installed OS image or the like does not in general care about updates to the software they have running.

Most people just install and forget, and if it weren't for in-app auto-update, most people would never upgrade.

Reply on news.ycombinator.com