UNIX admin wrote:
The full list of publication tools are:
pkgdepend(1)
pkgdiff(1) -- build 130+
pkgmogrify(1)
pkgrecv(1)
pkgsend(1)
Please note that pkgsend will allow you to import an
existing SVR4
package (minus class action scripts), directory, or
tarball as the basis
for a new package. The man page explains all of
this.
Yeah, so what happens if my SVR4 package doesn't deliver any files, but does
all the work in those scripts instead?
Then you'll have to re-create your package.
I still disagree about two main things, and those are that
1. there should be no pre- and postinstall scripts, i.e. only files should be
delivered
That's fine, we'll just have to disagree. See this blog entry for more
information:
http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting
Except, it isn't quite correct say that pkg(5) only expects "files" to
be delivered. It also allows for groups, users, drivers, SMF related
items, and legacy SVR4 information.
2. that SMF should be *ABUSED* as a backdoor for executing those.
You view usage of SMF as an abuse, but I view it as a change of
execution context. pkg(5) doesn't say that you can't have scripting, it
just says that you can't have scripting as part of the package execution
context.
The fundamental problem is that the IPS packaging team believes that the
definition of a PACKAGE is ONLY that of *FILES*, while customers
(aforementioned military, banks, insurance companies, and fortune 100 companies
in general) believe that a *PACKAGE* is a UNIT OF CONSISTENTLY REPEATABLE,
ENCAPSULATED *WORK*.
Every packaging system has a different definition of what a package
can/should consist of. pkg(5), like other systems, has chosen a
different definition or view of things. There is nothing stopping you
from continuing to encapsulate the set of repeatable work you desire to,
but you will have to do so in a different way than you used to.
If you must cause pain, how about developing some sort of method to
automatically migrate pre- and postinstall and pre- and postremove scripts to
one or more one-time SMF methods?
There are no plans to do so at this time, although that might be
possible in the future. Given that most of those scripts didn't work
reliably in the past in all execution contexts, I doubt the conversion
would be as useful as you might imagine.
With that said, there has been a discussion of how to simplify delivery
of these scripts to ease transition.
Cheers,
--
Shawn Walker
_______________________________________________
opensolaris-discuss mailing list
[email protected]
