Peter Tribble wrote: > 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.) yep bzip2 is the major culprit really. > > Packaging is slow. There's an awful lot of low-hanging fruit here. indeed, a lot could be done to improve this and patching sa well, > > Patching is very slow. It can be very much slower than can be accounted > for by manipulating the constituent packages. did some analysis of this using recommended cluster from about 6/06 time frame, now my conclusion was that patch packages for core Solaris tend to be quite sparse, even say the kernels's for 8/07 are actually quit sparse, lots of packages with only a very small deliverable content. In the case of the recommended patch cluster, there were 262 packages in total of which 116 only delivered 1 file. we had actually converted the i.none from sh to C binary, but due to the extreme sparse nature of the patches, I only saw an 8% gain doing this. On the other hand some application patches ( such as pyton, tend to be fully populated patches,and we saw a near 50% gain from a C binary i.none.
Also the patches in the recommended cluster make use of "deletes" files, which is handled by postinstall, each line in a deletes file is processed individually, so for each line we call removef which maniplates the contents DB, l;eading to major IO going on, Actually removef was the second biggest Io consumer in add the recommended patch cluster. So basically lots of low hanging fruit :-) > > 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. yes the whole zones boundary, versus usr and root packages are not so good, pretty much zones has no real bounary as such in realtion to files and packages. > > 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. would be nice, but this is kinda hard to accomplish really. By this I mean the whole single user, reboot immediate and so on. My recommendation is not to patch live systems, use Live Upgrade instead, much easier, and give the ability to reverse the change easily and without undue consequence. > > 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. caused mostly by backporting of features to update releases. Again current patch/packaging tools are not designed to handle this, they were designed to apply simple bug fixes, all in the distant past, we badly need investment in this area. Which is why I'm happy to see projects addressing this area in opensolaris. > > 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. yes, totally, tools that work properly are kinda a basic requirement :-) > > 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. yes, currently a major black art goes on with editable files. > > 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.) > >
