Re: Non-privileged user package management
On Tue, Jul 29, 2008 at 07:58:04PM +0300, Teemu Erkkola <teemu.erkkola@tut.fi> was heard to say:
> Reading the new features of KDE 4.1, I had an idea (which may or may not
> be something someone else thought of decades ago, and which is
> implemented in other package management softwares, but not in apt for a
> very good reason).
>
> Why not let non-privileged (normal) users take advantage of the package
> manager software? They could install the programs they want into their
> respective home folders, as many do already without the help of a
> package manager. Combining this with a one-click-install from a web page
> could really boost the overall usability of apt-using distributions in
> the eyes of the average Joe.
I've thought a few times about what would be necessary for this. The
basic problem you hit is that you would need to come up with a mechanism
for allowing packages to be relocated: that is, work out a scheme that
packages can use to find themselves and their dependencies. (if you
don't do dependencies it's a lot easier, but you need to be able to find
dependencies to, e.g., install a new version of KDE)
The actions that are necessary reparent a package or to make a
reparented package available are completely dependent on the package:
you can set LD_LIBRARY_PATH to pick up a library in an unusual place,
for instance, but you need to do something totally different to pick up
a relocated Haskell package. So at the package management level, all
that's really feasible, I think, is to define some basic mechanism: for
instance, call the postinst with a "relocate" argument that sets the
package up to run relocated. Probably you could define some Debhelper
magic that generates postinst snippets to handle relocation. Once
you've done that, "all" you have to do is convince the maintainers of
software that you want to use in a relocated manner to redesign their
packages to allow them to be relocated. You also need to ask the same
thing of the maintainers of any dependencies you want to install.
Once all that is done, we can start thinking about what happens when a
package you want to install locally conflicts with a globally installed
package or requires an incompatible version of it.
In other words: it's a nice idea, but it would take a great deal of
work and a great deal of buy-in from many different people, to cover a
rather small use case, and it might never work quite "right" anyway. I
think it might be a fun problem to try to solve, but it's also a
gigantic one. And most of the work that needs to be done is at the
level of dpkg, not apt.
Daniel
Reply to: