Shawn Walker wrote:
> This sounds a lot like you're wanting the ability to run arbitrary
> commands as part of packaging.
Give or take the definition of "packaging", yes. As part of the
software management lifecycle.
> I'm not really for that since such actions aren't really "auditable".
>
> One of the biggest disagreements I have with most packaging/installer
> mechanisms is that they don't restrict the set of possible actions, so
> packages/installations are free to "run amok" amongst your system.
Er... none of the proposals here change that. All they do is to push
the "run amok" stuff into some separate part of the overall process. If
anything, they make the problem worse by pushing it *out* of the
relatively controlled environs of the package scripts and into the
jungle of actual application execution.
If all of this kind of stuff is expected to be done by package scripts,
you can inspect the package scripts and ensure that what's done by
install scripts is undone by remove scripts, that files are updated
properly before the actual program runs, and so on.
If it's pushed later...? How can you know what set of system
configuration files the program plugs itself into? Plus, of course,
what's going to *unplug* it when it gets uninstalled?
> * How do you ensure that package foo does not alter or otherwise
> change the configuration of package baz?
Well, first, it might be *supposed* to change the configuration of
package baz. I would hope that my FireFox add-in changes the
configuration of FireFox; that's what it's for.
Second... how do you know that *executing* foo doesn't inappropriately
change the configuration of baz? If foo, through whatever mechanism,
inappropriately mucks with baz, it's a bug.
> * How do you ensure that these configuration actions are auditable and
> reversible as part of the uninstall? (i.e. if I said uninstall, I
> don't want six different configuration files littered over my system)
If the configuration actions are performed by some separate
after-installation mechanism, how do you ensure that they are undone on
uninstall? Heck, how do you even *start* to get them done on uninstall?
At least the *install and *remove scripts give you clear control points
for reversing the change.
> * In the cases where you intentionally have package
> really_neat_apache_module alter the configuration of apache_server,
> how do you record that configuration change?
Good question. How do you record it when configuration is altered by
the module's after-installation SMF script, or by its external
installer, or by its actual execution?
In SVR4 packaging, I'd personally say that the right answer is that the
module should "deliver" the files that it updates, using class action
scripts to actually do the updates (and backouts on uninstall). That
way the package subsystem records that both the server package and the
module package "own" the file. Not that we use it that way.
> * Where is the boundary between the bits that are installed and
> configuration changes? In other words, how do we prevent configuration
> of package foo from removing valid files for package baz?
See the questions above. Software that runs amok is broken, no matter
whether it's the software's install scripts or actual execution that's
doing the damage.
> * How do we deal with "pkg verify" if package installation can alter
> the delivered bits?
The SVR4 (and, I believe, RPM) answer is that files can be marked as
modifiable in the field. How does "pkg verify" deal with /etc/passwd?
My personal view is that the SVR4 packaging tools have two distinct ways
to deal with these cases, through the "ftype" parameter:
f Normal file, should never change from the distributed
version.
e File that might be modified during this installation;
update its checksum after installation. Note: multiple
packages might contribute to it. File should not
change outside package installation.
v File might change at any time, by system operation or
user action.
There is no consistency in Solaris use of e vs v and no consensus as to
the true, practical distinction between the two. The tools treat them
nearly identically. (Which is a bug in my view; I believe pkgchk should
treat e files like f files, and should ignore the contents of v files.)
But again, it seems like you're just moving the problem. How do you
deal with "pkg verify" if executing the application can alter the
delivered bits?
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
