Nicolas Williams wrote:
>> There are those who believe that an attempt to uninstall a running
>> service should be rejected.
>
> Note that this is something that the pkg system itself could enforce
> should it really matter.
>
> Package removal vetos can/should only really relate to some sort of
> dynamic dependency(ies) not known to the pkg system. I can't think of
> any other than "the software to be removed is currently running," which
> in the case of SMF services is easy to detect/address.
>
> So I see no need for preremove scripting or porting of such scripts, at
> least not w.r.t. removal veto.
Interaction with SMF might well address the possible need for removal
vetoes for services-running. Whether it completely addresses the need
for preremove is less clear to me. For instance, when you go to
uninstall Adobe Reader, one of the things that should happen before you
actually remove the executable is to remove the entry in /etc/mailcap
that refers to it. (Granted, race conditions still cause problems.
Still, it seems tidy to keep the system consistent at all times.) While
that (and all such file-type associations) could be modeled as an SMF
service, doing so seems like something of a stretch.
My real worry in eliminating scripting is a fear of the unknown.
Package scripting (and many other forms of plug-in scripting) serves as
an escape hatch for any number of specialty requirements, allowing them
to be addressed in a semi-controlled and mostly-modular fashion. It's
difficult to be confident that all of the needs have been addressed when
they are so varied. (On the other hand, eliminating the escape hatch
forces software designers to use alternative mechanisms, perhaps pushing
them into cleaner designs... or perhaps into more awkward, unreliable,
and unmaintainable designs.)
> IIRC preinstall is like checkinstall: it can gather data needed by CAS,
> but unlike checkinstall it requires no interaction, so that pkgask(1M)
> can be avoided for pkgs that have no checkinstall script. Since there
> are no CAS in IPS there's no need for this SVR4 packaging cruft.
I'm not sure of the relationship to user interaction, but there are
other important differences. Checkinstall is run as an unprivileged
user; all it *can* do is to collect data and perhaps veto the
installation. Preinstall, on the other hand, is run with full
privileges. It is expected to modify the system. Uses include:
- adding users before installing files owned by those
users.
- preserving files before upgrades (which would be better
done using class action scripts).
- shutting down services prior to upgrading them.
- recording the installed/uninstalled state of the package
before installation, for use in deciding whether to
enable a service after installation. (This is remarkably
common in ON packages, and probably merits special attention.)
- cleaning up system state before an upgrade - e.g., removing
obsolete entries in configuration files.
I'm not trying to claim that IPS hasn't or can't address those needs,
just trying to enumerate some uses that I've seen.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
