> See "man pkgsend.1", specifically the "generate"
> subcommand, in builds
> 118 or later. Although I'd strongly recommend build
> 129 or later due to
> the significant improvements that have been made
> since then.
So, that explains a whole lot. Last time I studied this technology was at
build 114.
> 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?
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
and
2. that SMF should be *ABUSED* as a backdoor for executing those.
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*.
How do you plan to reconcile those two views? Or are you going to outright try
and FORCE people who have developed these technologies and have had them
working for the past decade or more?
You know, customers have one advantage over the IPS development team, they have
existing technology and experience already in place and know from *EXPERIENCE*
that the definition of the "package as a unit of consistently repeatable work"
works, and works very well.
On the other hand, we have the IPS team which is constantly saying "IPS is the
way to go", and "we're not done yet, and we don't know what the final product
will look like, but we're confident that our way is *better*".
So, what of it?
Now, even the abuse of SMF wouldn't be so terribly bad, SMF supported one-time
SMF manifests, which it currently does not do (although it was planned), and
the fact that adding one's own instances of a known service ("smtp:abcd") is
currently non-trivial and REQUIRES quite a but of svccfg(1M) scripting.
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?
And, one problem which I could not solve, if you think of packages as a unit of
work, and we have one-time SMF methods emulating pre- and postinstall and pre-
and postremove scripts, how does one ensure that a sysadmin doesn't
accidentally enable an SMF method which is the equivalent of a pre- or
postremove SVR4 package script?
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
