[HerraBRE]

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.

[drdaeman]

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.

[HerraBRE]

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.