[Rpm-maint] Some ideas about non root software installation (was: [packaging] RFC: Berlin Packaging API)
domi at komarr.grenoble.hp.com
Thu Feb 28 13:19:52 UTC 2008
[ Looks like my previous mail did not go through. Apologies if you
receive this mail twice ]
Edward Welbourne <eddy at opera.com> writes:
> Make it easier for us to ship packages, that unprivileged users can
> install, and we'll be happy to let the tools you've provided insist
> on us living under /opt/.
I've been toying with the idea with the following idea to address this
If we want a unprivileged user to install software, this means either:
- the user can gain root privilege (which we may not want)
- the user can interact with an application that will sanitize user
input and perform privileged operation like installing files in root
areas (ie. /usr/bin or /opt/something)
If we follow these requirements a "universal" package would bring a
bunch of files with some metadata. This "universal" package would
*not* specify where to install the files.
The metadata would specify the kind of files contained in the package:
executable, public library, private library, doc files, menu entries,
message files, architecture independant data, daemon...
It would be up to the privileged application (provided by the distro)
to decide where to install the files. Executable could be installed
directly in /usr/bin/ or /opt/foo/bin depending on policy. Data files
could be installed in /usr/share/foo or /opt/foo/share.
The priviliged application would also need to provide a file listing
where the "universal" package files are installed.
The main constraint for ISV software would be to exploit this file
listing to find where are its private libraries or data
files. Executable and public libraries could be found with usual
mechanism (PATH and ld.conf)
Another constraint: package script would be forbidden because they can
be run as root.
In essence, we'd define not an API for universal package but a
protocol between a "package" entity provided by ISV and a "package
entity" manager provided by distro.
Like all protocols, it would bring a set of constraints for ISV and
distros, but if widely accepted (and detailed enough) it could bring a
lot of benefits for both ISV and users.
Do I make sense ?
Could these constraints be acceptable for ISV ?
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner
More information about the Rpm-maint