While there exists an OpenSolaris install strategy, that strategy explicitly does not encompass packaging and patching, for which a separate strategy is needed.
Development of such a strategy is sorely needed. Especially given current concerns over where packaging is headed. We should be asking: - What are the future needs that the package/patch system needs to address? - What are the shortcomings of the current system? - What steps need to be taken to fix the current problems and address future needs? ================8<====================== Some of my initial thoughts which aren't at this point broken down into the structure above: Installation is slow. (One primary cause is bzip2, but the tools aren't as efficient as they could be.) Packaging is slow. There's an awful lot of low-hanging fruit here. Patching is very slow. It can be very much slower than can be accounted for by manipulating the constituent packages. No direct update of packages - you should be able to replace one version of a package by a (compatible) version without having to delete and reinstall it. Ditto patches. For both of the above updates, it should be possible to optimize by only manipulating the files that have actually changed between the two versions. Software isn't always broken up into packages that reflect the needs of the end user. Some packages are too large and are an impediment to minimization; some are too small and have no value in being separate. Packaging shouldn't have intimate knowledge of technologies like zones. In particular, splitting software up into multiple packages shouldn't be used as a mechanism to determine what does and doesn't get installed in a zone. Network repository. What matters most is that the network repository exists, and that there is a catalog of what it contains. Until we've gained experience of the usage patterns, it would be premature to build anything other than the most basic of tools on top of it. It should be possible to evolve major parts of the system independently. For example, the version of the desktop shouldn't be tied so rigidly to the version of the kernel that it is at the moment. Any system must support all existing SVR4 packages. This support must be built into the system - no external conversion required. Any system should support all existing installers. I would love to uprate this to a must, but that would probably be overly prescriptive. In particular, I would hope webstart installers would still work. Need a new delivery format. Filesystem format isn't suitable for networked delivery; datastream is ugly and inflexible. See my ZAP proposal for a possible format. Should be possible to reproduce a system configuration. So the system should be able to document exactly what is installed, in a format that can be fed back into the installer. While obtaining software from a network repository should be supported, it should not be exclusive. Installation using any media must work. The possible solution where the end machine must have a local network repository doesn't meet this requirement. Software suppliers must be able to supply their software by any means. We must not require them to run a repository, distribute their software via someone else's repository, or in any way require them to modify their software distribution mechanisms. It must be possible to override the system's dependency evaluation, allowing the installation of packages without fully satisfied dependencies and the uninstallation of packages with dependants. It must be possible to install/uninstall at the per-file level. (I expect the uninstall case to be the most commonly used.) If automated dependency resolution becomes available, it must be possible to turn it off. Groupings of packages (ie. clusters) should be first-class citizens. Packages can belong to multiple clusters, and clusters can contain other clusters. Removal of a cluster removes all its packages that aren't in other clusters or required for dependency resolution. Patching shouldn't require the system go down to single-user or be in any other non-functioning state. Patching applications should not require a reboot. A restart of that service, at most. We must never have something daft like 119783 (the dns patch that requires a reboot). Need to avoid the tangled mess of dependencies and barriers introduced by the S10U3 and S10U4 kernel updates. Should allow driver updates without a reboot. (Shut down service; unload driver; apply patch; load new driver and restart service.) There are likely to be limitations here, of course. Shouldn't rely on filesystem features to function. Patches that go together should be merged into single patches. We want tools like pca or patchdiag; we don't want things like the update connection. Currently the inventory only supports simple checksums - these should be at least md5. Ought to integrate functionality like tripwire directly into the package system. (Sun also have some database of file checksums that would be useful to hook into.) Need to tighten up on the notion of editable files. Specifically, need to know if an editable file has been modified outside the packaging system. Should have a proper API to allow alternative language bindings. Minimize the requirements of the package system itself; the package system shouldn't prevent the construction of a minimized system. Would like to be able to create policies, such as 'install all relevant manpages'; the package management system itself should not have any knowledge of the meaning of any of the policies. (In other words, the packaging system should be completely unaware of the notion of man pages, but should have enough versatility to allow arbitrary policies to be added at any time without changing the packaging software.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
