Simplifying package installation (was: replacing XMMS)

[Michael Schwendt]

On Mon, 26 Apr 2004 09:01:05 -0400 (EDT), duncan brown wrote:

> while i'm on this track, i think rpms need to be able to be installed by
> any user, but only into their own home dir and accessable by themselves
> only.  joe's logged into gnome and wants to install cd2ogg, but he doesn't
> have root access... sure, he could grab the .tar.gz and just put it in
> ~/bin and add that to his $PATH, but that's what we want to get away from.
>  he should have the ability to have rpm install the script and any
> dependencies that aren't already resident on the system into his own ~/bin
> or whatever directory.

First the software must be made fully relocatable and, for instance, find
its translation modules and not expect its data files in a location that
was hardcoded at build-time. And of course, it must ignore a global
instance installed into the system by the administrator and allow for
switching back and forth between local installation and system-wide
installation (e.g. in its configuration data).

> now, let's say that root installs the cdparanoia
> package a month after joe installs it into his userspace's rpm database. 
> the root rpm database checks the joe's rpm database (let's say
> ~/.myrpm.db)  to see if anyone else has cdparanoia installed and then
> either removes the rpm in joe's user space, or (as joe should have the
> option) leave it alone and let joe keep on using it.

Does this scale? And what about security flaws in the locally installed
packages?
 
> but we're not talking about redhat-install-packages.

No, we're not. But it illustrates some of the problems with random
packages downloaded of the Internet.

> fedora and extras don't have mono in their
> repositories, but the user wants to use it.   they should be able to just
> click a link on mono's site and have mono added to their semi-trusted list
> of places to get software.

Assume the following packages (
http://www.go-mono.com/archive/0.31/fedora-1-i386/ ) install cleanly in
Fedora Core 1 if they were contained within a repository and you could add
that repository easily to your favourite package utility.  One of the
Fedora Project's objectives is "Create an environment where third party
packages are easy to add and positive encouragement and support exists for
third party packaging." Common meta data for yum/apt and others are one
step on the way to making access to repositories easier. The jump from
a loose collection of binary rpm files offered at some web site to a
one-click installation is not a small one.

> i don't see how the simplicity of installing a piece of software on
> windows is an orange to the apple of linux's rpm/deb/etc.  and yeah, you
> get dependencies, but they're so RARE.  and they need to be able to be
> non-existant as far as the user having to do research on where to find it
> and the correct version for their system.  just because windows has a
> bug^H^H^Hfeature like gui windows notifying you of a dependency, that
> doesn't mean we need it too.

It's a bad comparison in that with packages created by arbitrary open
source software projects we face a different dependency scenario, in
particular if a package contains explicit dependencies added manually by
the packager, which do more damage than helping the user. For instance, a
simple version mismatch between the installed version of Python and the
required version of Python, or a different package name used on different
Linux distributions, and a package would refuse to install (and I don't
even cover cross-distribution package compatibility). Compare that with a
proprietary system.