Comments on: pkg(5): a no scripting zone

By: Thomas Wagner

Thomas Wagner — Tue, 18 Sep 2007 15:40:31 +0000

@Matt: I have a dream: Install the packages for Apache, Database, Scripting-Language and the Application (e.g. Typo3). The dumb packages do almost no configuaiton (minimalistic scripting). The pieces are glued together by configuration recipes which can be tweaked by site-local profiles or an interactive dialog with the administrator.

The big advantage would be, simple standardized base packages are the basement for multiple use-cases, where the more complex configurations tasks are covered by 1 configuration-recipe for the whole stack.

By: Matt Ingenthron

Matt Ingenthron — Fri, 14 Sep 2007 23:53:00 +0000

First of all, excellent work, the prototype looks impressive!

So one question is whether or not there continues be a concept of 'clusters' and what kind of public interface or knowledge of clusters pkg(1) has. The reason I ask this question is in Solaris there's a limited set of clusters, but there are clearly reasons people may want to have variations on clusters of higher-level packages. Each one of those may have different configuration defaults.

You probably know one project I'm thinking of that could use something like this (Web Stack), but that's not an exclusive use case. There are say, with Java Enterprise System, use cases where you'll configure a portal server against a webserver, or a portal server against an application server. Right now, that whole area has something even more ugly than pkgask and friends (IMHO), but it sure would be nice to be able to provide OS level support for clusters of packages, configuration and all, to things outside Solaris itself.

By: Stephen

Stephen — Tue, 11 Sep 2007 19:22:36 +0000

@nacho: I’m writing the project proposal for the Installation CG to approve now. I don’t claim we’ve solved every issue by any means–we’re just coming out of a prototyping phase. — Stephen

By: nacho

nacho — Tue, 11 Sep 2007 05:21:23 +0000

do you know when will we have some more documentation about this? i’d like to know how you solved a ton of stuff, sysv packaging compatibility, dependency checking, i guess i’m just a curious idiot

By: Stephen

Stephen — Mon, 10 Sep 2007 17:31:44 +0000

@nacho: The scripts generally are either inspecting or modifying the destination image to bring its aspects into line with the package's expectations. Such modifications are generally to components that represent configuration in some fashion. By moving scripting out of packaging, we limit the contexts the script developer must consider: for instance, scripting in smf(5) means that there is a running system atop the image.

@dominik: Yes. The present plan is to leave System V packaging in place for compatibility, but not to use it for any of the packages delivered as part of the distribution. "New" system packages will provide, up to a point, aliases for the legacy packages they replace. The benefits are believed to outweigh the costs imposed on consumers of the current packaging APIs.

-- Stephen

By: dominik

dominik — Mon, 10 Sep 2007 10:36:18 +0000

Removing the ability to run scripts during PKG installation will break many customer made scripts which are depending heavily from this feature. I know of a some big companies whose concept to distribute software will be at question if the scripting interface in pkgadd would be removed.

By: nacho

nacho — Sun, 09 Sep 2007 18:32:18 +0000

you've made an interesting assumption there, you basically just said that the only reason those scripts exist is to configure the services but is that really so?.
also getting rid of the said scripts and moving that to smf (or another mechanism you havent explained yet) doesnt solve the problem, it just moves it to another layer and since smf scripts are just scripts you still have that opacity.
am i missing something?

By: Stephen

Stephen — Sun, 09 Sep 2007 18:08:21 +0000

@nacho: Yes, although smf(5) isn't the only mechanism we could utilize.

@MC: The "Preparing... Retrieving... Installing..." are all pkg(1) operations. The SMF lines are fix-ups in the zone install, until we construct the "preserve" action and "opensolaris.zone" facet handling. Then this installation process should be purely pkg(1)-based (which won't be true for all installers, of course).

-- Stephen

By: MC

MC — Sat, 08 Sep 2007 09:41:38 +0000

Progress is wonderful!

So which part of that transcript is the UPS prototype )

By: nacho

nacho — Sat, 08 Sep 2007 07:34:08 +0000

if i understand correctly, the problem with the current (scripting) approach is that there are simply too many situations in which the package should work but the packager might not have considered at the time he created the package, and that. what you seem to be proposing is that initial/update configuration of the package should be left outside the packaging framework and instead be handled by smf
am i on track?