pkg(5) seems to use a set of actions to define what and how to do things, and they seem to be similar to plugins in that you just drop the action file in a directory and things work. check http://opensolaris.org/sc/src/pkg/gate/src/modules/actions/ does the plugin list get updated every action that is taken? cant i install a package that delivers an action and set a have a package depend on that one? is there any predefined order in whch those actions run?
nacho On Sun, Dec 13, 2009 at 9:58 PM, Shawn Walker <swal...@opensolaris.org> wrote: > 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 > opensolaris-discuss@opensolaris.org > _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
