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.
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.