Comment by drdaeman | Hacker News Reader

Comment by drdaeman | Hacker News Reader

I'm just an ordinary user, but I'd put my 2¢.

Nowadays, any developer can create a packages for his application (and any of its dependencies) and publish it in self-hosted repositories. Users can easily add such repository to their system's sources list and bureaucracy problem's over. Well, some developers are doing this already - the only thing that keeps the rest of them is either ignorance or complexity of the packaging process.

I believe there's no need for an Android market clone (which is yet another centralized repository). What users may need is just a directory, pointing to external repos. Ubuntu market seems somehow promising (at least I remember seeing some dialogs like "you need to enable this source to install that package").

Content duplication is not a problem. A real problem is keeping the system up-to-date when you want to update some library, because of an important feature or bugfix. And it's nearly impossible with every application's bundling their own copy of that library, with some copies being actually incompatible forks (and a lot of copies being just different builds - think of different compiler versions - of exactly the same sources).

What you think is easy is actually not easy. Any time you've added one, two, three more steps to a problem after clicking the link in the browser you've already lost. Adding repositories? Already too late. Touching the command line? Sorry, as much as we love it, for most users it's already too late. Going into Aptitude or Synaptic and pasting in the repository URL? Yep. Too late.

This is all compounded by the fact that there is no app bundle. Mac OS X has the bundle and a terrific way to install it: Drag and drop it into the Applications folder, just like we did in the days of the Mac Classic and MacPaint. It hasn't changed. (Well, it did for a while, but thankfully they went back.)

If you say, "Well, that means you end up installing 5 different versions of the same library on the same system" - Who cares? Disk space isn't a priority any more, and from a developer standpoint it makes a lot more sense to target a dependency whose version number I know, instead of a dependency whose version only the package maintainers know for sure. I don't want to be forced to target v1.3 of a library if it's only been tested (by me) on v1.2. It makes for much better application stability for the developer to be in control of dependencies and not these package maintainers.

I want to ship a self-contained bundle of awesomeness, not a dysfunctional shard among ten thousand other shards.

Maybe the experience is different on other systems, but on Fedora with KDE there already is no friction to installing random stuff. If I want to install, say, Google Chrome, which is not in the normal repositories, all I have to do is download the package and open it. A nice GUI program then takes care of the rest for me automatically; the main differences from installing a program on Windows is that it then updates automatically and I have to enter my password.

So really, there is less friction than on OS X--I don't have to drag anything anywhere! In fact, on Firefox, I just download the package and it figures out to open it with the right program automatically. And then it just works.

Of course, if a program is in the repositories it's even easier, but that's a different story...

This is all compounded by the fact that there is no app bundle.

A "collection" type for installing multiple packages transparently would be nice, but I have to point out that nothing prevents you from doing the exact same thing that you do on Mac OS X, which is to distribute the .so libraries in the same package as the application, or even compile it statically.

Some of the bloat could be dealt with by the file system. If you download a library you already have, then simply discard it - and make do with a reference.

What I'd like to see, is the possibility of having multiple versions of software and libraries residing on the OS with ease.

I think these problems are surmountable.

> Adding repositories? Already too late. Touching the command line?

Nope. As simple as clicking a link with special URL scheme, like `apt+hXXp://archive.canonical.com?package=acroread?dist=feisty?section=commercial`

> This is all compounded by the fact that there is no app bundle.

I'm all for the bundles (which single-app repositories, actually, are!), but I want them to be non-monolithic (i.e. contain multiple separate packages).

I don't care about disk space — if I'm that constrainted with disk space that's probably another story that'll probably never happen to most ordinary users, having terabytes of storage. But I certainly care about bugs, and if libXYZ 1.2 has a critical one, I want my system to be free of that version ASAP.

And I don't care that you've never tested your awesome app with 1.3 — it's better to be possibly unstable than certainly unstable or, far worse, vulnerable.

What makes package maintainers uniquely qualified to patch dependencies and upgrade them? Either we say Canonical or Red Hat hires the best possible people to watch over their package repositories or we say that a qualified application developer could do just as well. Either way we end up having to trust somebody.

Both package maintainers and developers have an interest make sure their programs don't introduce vulnerabilities into the system. Therefore if there's a serious problem with one of their dependencies vulnerability patching will happen either way.

The distribution maintainers should be in charge of maintaining a core set of low-level dependencies that are needed by many applications. Beyond that they should leave the dependency management to the application developers. Seriously. That would free up so many millions of man-hours of work for say, Canonical, that they could actually make the core system usable to the average user.

"And I don't care that you've never tested your awesome app with 1.3 — it's better to be possibly unstable than certainly unstable or, far worse, vulnerable." Not all library bugs affect all programs though. If you change a library and break things, then the user usually has to wait for the maintainers to fix it, even if the programs would not have exposed the vulnerability. I am thinking of something like a program that uses libPNG to load included images that might break because libPNG has been changed because malicious images could cause a buffer overflow.

I do this at http://pagekite.net - I build both RPMs and DEBs and host my own repos. This works fine for the most part and is relatively easy for technical users to take advantage of. It was a bit of work to get it working (and my packages arguably aren't good enough yet), but it's doable, even for a small shop like ours.

The problem is, this is horribly, horribly insecure.

If you add my repo to your sources.list, I can offer a "security update" to any app on your system, a binary which does anything I want.

Obviously, it would be signed by me and could be traced back to me, and I would never do that ... but it would still be a really bad idea to go around adding repos to keep up with the latest GNOME FartButton Free. Add 1000 repos, and the odds of a successful hack or a stupid packaging mistake breaking your system go up by at least that much.

Package managers certainly need improvements.

Repositories must declare what packages (or, better, package name prefixes, like `foobar-*`) they intend to host, and package managers must restrict them from installing something not from this list.

Then you can, for example, host your own libsqlite3, but it'll be namespaced as foobar-libsqlite3 with some `Duplicated-By: libsqlite3 (tested with >= 3.7.3, <= 3.7.7)`.

[Added after some thought] Or, better, let's just namespace package names, based on DNS. I.e., a repository at sqlite.org can provide org.sqlite/sqlite3, but not org.kernel/linux2.6. Obviously, trusted repositories won't be subject to such restriction.

Yes, I do think this could be worked out - the packaging infrastructure we have today is really powerful and could be built upon. No reason to throw out the baby with the bathwater, I just wanted to illustrate some of the obvious drawbacks of the current "state of the art".

I really hope the ideas from the OP get some traction, Ingo makes some very good points which I haven't heard expressed so well before.

Reply on news.ycombinator.com