[Rpm-maint] Some ideas about non root software installation (was: [packaging] RFC: Berlin Packaging API)

[Dominique Dumont]

[ 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
concerns:

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 ?

HTH




-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner