On 10/3/07, Stephen Hahn <sch at sun.com> wrote: > * Stephen Hahn <sch at sun.com> [2007-10-02 22:03]: > > So, the relevant Indiana requirements, as they coalesced, are also > useful, because there was a public negotiation around them as well, so > we can assume that the text was debated to some level of acceptance. > The ones I pick out from > > http://opensolaris.org/os/project/indiana/documents/problem_statement/ > > are > > INS-2: Existing installations should allow a seamless upgrade to the > next consecutive stable release or future releases within > certain well defined boundaries.
Have those boundaries been defined? What's reasonable here? The first problem is to define a "release", because in Solaris that could be overloaded, with Solaris 10 and Solaris 10 update 4 being both the same and different releases depending on context. I suspect the boundary definition would be made by individual distributions. And maybe 2 years or 2 "full" releases as a minimum. > PKG-1: Provide package management infrastructure that allows easy > install, configuration and removal of software with full > dependency checking and a 'just works' experience. I note that dependency resolution isn't included. And the focus here revolves around the rather subjective nature of the user experience, where 'easy' and 'just works' need further definition. I suspect the Indiana requirement is for a simple GUI. Should the packaging system itself provide a GUI or provide a stable API that allows a variety of user interfaces to be developed? > PKG-2: Software will either be installed by default on a single CD, or > easily available over the network in binary form through package > management tools. Are we excluding source-based distribution from the strategy? > PKG-3: Software should also be available in meta clusters for people > to install specific to their needs eg. Web 2.0 meta cluster. There's a slight ambiguity there - are just the cluster definitions available, or does this imply that whole clusters are available as single entities? > PKG-4: An existing network repository can be easily mirrored, and > users can appropriately configure their system to install > packages from there instead. I would take this a little further; mirroring should not require special software or anything beyond putting files within a known structure on a network accessible server. It shouldn't be necessary to use or configure any special software in order to create a repository. > PKG-5: Provide a series of tools to allow developers to create and > maintain their own set of packages as part of an unsupported > package repository, or propose them for a supported package > repository. Does the use of those tools require that the package creator has to be running the release on which they're to be deployed? Why shouldn't someone be able to build their software on Solaris 8 and package it up for late systems (where it should run given the compatibility guarantees built into Solaris)? > PKG-6: Packages will be upgraded as appropriate through an automatic > update facility and notification to the user. There's a possible interpretation of that in which it can't be turned off. The system should be capable of updating software, and should allow both automatic and manual updates, with user-defined policies. Notification is interesting. Who gets notified? In the general case, the user of the system and the administrator of the software on the system are different. There needs to be a much better story as regards enterprise management of updates. > PKG-7: It should be possible to preserve the current environment prior > to an update so that a rollback is possible in case of > breakages. There are two requirements. Rolling back is great for when your system gets hosed. In addition, it should be possible to reverse an individual update without rolling back other parts of the system. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
