I would like to create a subproject to maintain a version of IPS for Solaris
10/OpenSolaris Nevada. This would allow software porters to use IPS to port
packages not only to Indiana, but to Nevada. Right now it is really annoying
for a porter to support both Solaris 10 and later versions. We have to
maintain two sets of installation documentation, two sets of package files,
and two sets of upgrade instructions. Further, to support Solaris 10 we have
to write scripts to emulate what IPS does for us automatically. Some things
that are very simple with IPS are very tedious and dangerous to emulate with
SRV4 packages (e.g. line-by-line three-way-merging of entries in
/etc/passwd) with preinstall/postinstall scripts. 

The Web Stack team has already advocated the installation of Web Stack
components on Nevada:
http://blogs.sun.com/jyrivirkki/entry/web_stack_package_repository

The subproject would have the following goals:

1. The user must be able to install the package using pkgadd:
   pkgadd -d http://pkg.opensolaris.org/.../OSOLipkg-nevada.pkg
Installing the package would bootstrap the SUNWipkg IPS package. That is,
after installing this SRV4 package, there SUNWipkg would be installed as a
IPS package. That way, IPS can upgrade itself.

2. IPS on Nevada would not be able to upgrade any SRV4 packages. IPS would
maintain a blacklist of packages that should never be installed with IPS on
Solaris 10/Nevada, which would include all packages that Sun issues SRV4
patches for on SunSolve. That way, the supportability of the system is not
compromised.

3. OpenSolaris projects that are designed to be compatible with Nevada (e.g.
Web Stack) must support IPS on Nevada. Contributors will be encouraged to
build IPS packages that are compatible with Solaris 10 whenever possible. If
a package only works on Indiana then its IPS package should have at least
one dependency on a package version that is in Indiana but not Nevada. 

4. The package would be installable in a Solaris 10 sparse-root non-global
zone. That is, it can be installed into /opt instead of /usr/*, which is
often read-only.

5. There would be one version of the SUNWipkg package for both Indiana and
Nevada. In order to avoid taking resources away from Indiana, the initial
work of building the SRV4 bootstrap packaging, patches to SUNWipkg needed to
support the above requirements, and the ongoing testing of SUNWipkg for
Nevada could be delegated to a team separate from the main IPS team (and I
volunteer for this team). The main impact on the IPS team would be a
possible reorganization of the code to compartmentalize Indiana-specific
functionality.

Thoughts? How can I move this forward?

Thanks,
Brian

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to