Re: Are "user space" RPMs possible?

[Jeff Johnson <n3npq nc rr com>]

bernholdtde@ornl.gov wrote:

> I'm involved in a project that's looking for a convenient way to
> package and distribute both binary and source distributions of
> software.  However only about half of our developers have root on
> their Linux boxes, and there are other very valid reasons someone
> might not necessarily want to build RPMs or install them into the
> typical locations.  They might want user-private or group-private
> installations carried out by "normal" users.
>
> I've already found documentation on how to build RPMs without root,
> and it seems that if we make them relocatable, we can install them
> pretty much wherever we want.  
>  

With --badeloc. any path can be relocated, even if the package is not 
relocateable.
Note carefully that
   a) there is no guarantee that pkg contents are functional after 
relocation.
   For example, any absolute path compiled into programs or hidden in
   config files is *not* relocated.
   b) --relocate has been broken in at least 2 recent releases of rpm

> However it is not clear to me whether RPMs can actually be installed
> by anyone other than root, and how things would work on a multi-user
> box, where multiple users might want to have their own separate local
> installations of the same package.
>  

There are several factors that determine whether non-root can install 
packages,
all having to do with non-root privileges:

   a) all install paths must be writable.
   b) chroot(2) is root only, so --root cannot be used
   c) the database must be writable by non-root.

> It appears that it would not be hard for each user to have their own
> database.  But what about dependencies on packages installed
> system-wide by root in the "standard" database?  Can rpm handle
> multiple databases simultaneously? (It seems to me that the ideal
> behavior would be to accept, say, multiple colon-separated paths for
> the dbpath option.  The first would be updated by the package
> installation; the others would be read-only to check for dependencies,
> etc.  This way, you could maintain user, group, and system-level RPM
> installations pretty easily.)
>  

There's more than the mechanism of opening multiple databases that needs 
solving.
Working through issues with mutiple provides, possibly with different 
versiosn,
or lack therof, have not been attempted. There's also the issue of 
choosing which
database is written when install is attempted. These are solvable issues,
but have not been attempted.

Adding users to group rpm to permit write access to /var/lib/rpm in 
order to install
pkgs with  relocated paths is likelier to be more manageable than 
multiple databases
imho. Users are not going to be able to change contents of, say, /bin 
because
they do not have write access there. Permitting write access rto rpmdb by
populating the group rpm depends, of course, on what your
site-specific needs and constraints are.


73 de Jeff