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

[Edward Welbourne]

> 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)

Or the user's installation is visible to root, whose next round of
running some update tool shall see it, show root details and tell the
distro package manager relevant details extracted from what the user
installed.

For example, root could set up a group for those trusted to be
sensible about installing ISV software; that group could then own
/opt/, using the non-distro package system to install packages in it,
which users could configure for their own use by setting PATH and
similar; but the non-distro package system includes a file in the
package that describes, for root's benefit, what would be worth doing
in order to make it generally accessible.  The distro package system
then includes a tool that knows how to scan /opt/ for new local
installations and remembers which prior ones root has either exposed
or decided not to expose to all users.  When root runs an update using
this tool, it tells the package system about any /opt/ stuff that's
been uninstalled and queries root to make a decision about whatever's
new.

The only way ISV-supplied scripts get run is by the less privileged
user (but in the /opt/ group).  The xdg-utils could be adapted to help
ISV-supplied scripts be minimal in what they do in /opt/.  The distro
owns the script to ingest details from new packages, so can take
suitable measures to limit the scope for harm in the general /usr/
area (let alone /bin/, /lib/, etc.), only installing desktop, menu and
icon files (for example) and updating the alternatives system,
perhaps.  A separate /opt/bin/ could be used to contain symlinks to
all the /opt/-supplied packages, that users could opt to include in
PATH (and root probably wouldn't); likewise for /opt/lib/ and
LD_LIBRARY_PATH, /opt/man/ and MANPATH, etc., so as to avoid polluting
/usr/.

> 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...

Makes sense.

> 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.

I lean towards the /opt/foo/* model, myself, with symlinks as above:
but, as you say, that's a policy matter for the distro.

> 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)

The non-distro package installer could add a config file, generated
based on the metadata in the package (e.g. indicating the name of the
environment variable it wants to use to discover where it's
installed), to an /opt/profile.d/ whose contents an /opt/profile could
source, providing user ~/.profile files with a handy way to pick up
settings of environment variables saying where each of the packages is
installed.  Each package would then consult its environment variables
to find where to look for its files; but could fall back on looking in
/opt/profile.d/$name to find the answer.

> Do I make sense ?

Reasonably, although there's endless scope for variations on the theme
- the hard part is chosing one variant that's satisfactory for all.

> Could these constraints be acceptable for ISV ?

Probably, with a little care in chosing how it's done.

	Eddy.