[indiana-discuss] "no scripting zone" and isaexec(3C) == architectural

[Bart Smaalders]

Peter Tribble wrote:

> Really, the job of a packaging system within this environment is to 
> do what it's told, move the bits, and get out of the way. It
> shouldn't be in the business of making decisions or trying to enforce
> policies off its own bat. All the interesting stuff is driven by
> scripting of some sort. If the packaging system helps us, then we'll
> take advantage of the facilities that it offers; if it hinders us
> then we'll have to find a way round it.

IPS will (when finished) strictly enforce the following policies:

1) All package dependencies are enforced:
      If a package has require dependencies, they will be installed.
      Packages may not be uninstalled if another package depends on them.
      Incorporations and minimum required versions are enforced.

2) The only action that's allowed to be duplicated in multiple
    packages that can be installed at the same time is a directory.

If these restrictions are too onerous, you don't need a packaging
system but tar or cpio may do what you want.

Why do we feel this is the right choice?

Because the job of the packaging system is to manage software
on the machine according to the constraints imposed on that software
by its developer, and by the administrator.

This is what permits us to (mostly) seamlessly upgrade from one release
to another without package history files, special code in a
release-specific upgrade program, etc. We use dependencies to
make sure that files moving from one package to another are correctly
handled, that editable files changing names or packages are correctly
handled, etc.  To allow the admin to defeat such controls w/ the use of
a -f option means that utter breakage is the inevitable result.

If as an administrator you wish to break package dependencies, divide
packages in half, etc, you need to repackage the software, because
you're now using it in a manner un-envisioned (or perhaps seen only
in a nightmare) by the original packager.  All the tools necessary
to do this will be part of OpenSolaris.

The design of variants/facets was specifically targeted at allowing
the package developer to describe a variety of different configuration
options.  If this mechanism doesn't provide sufficient flexibility,
please speak up.... but allowing administrators to perform ad-hoc
install-time overrides of the packaging system constraints is akin
adding bpatch support to pkg.


- Bart

-- 
Bart Smaalders			Solaris Kernel Performance
barts at cyber.eng.sun.com		http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."