Sorry about that mess...here's another try. > The initial area of confusion hits with the > distinction between packages and patches -- I know > there's a difference between releasing > functionality and fixing something that's > broken. That's not a distinction, by and > large, that is not made in the Linux world. If > I'm running > foo-1.1.1 and I need to update something, I find > foo-1.1.2 or greater. There's no question > that there's some downside with this approach, as > new functionality can risk breakage, but that's > what release notes are for. Similarly, package > naming and dependency resolution go hand in > hand. Why can't the package for > foo-1.1.2 be named that instead of 118974-37, and why > can't my attempt to add foo-1.1.2 at least notify > me of the other packages I need to add to handle the > dependencies and offer to get them for > me.
> Last night I was applying several security > patches to Solaris 10 11/06. Of the 8, 6 failed > to install with no information or explanation other > than a "failed" notice which scrolled away > from me fairly quickly. I don't know if it > was a dependency, a configuration, user error. > Had I not been watching it, I wouldn't have known > it failed at all. I think some of this starts out with the development model. New work all takes place on the next release after the production release (and I suspect a tiny bit happens for the one after that even). Bug fixes get backported if they're likely to be a significant problem, or based on customer demand. Other bug fixes probably come about when a bug is found or reported in a supported release that's not apparent in the release under development. Bug fixes probably involve for the most part the smallest set of changes possible (simplifying testing, perhaps), although the scope of a patch grows in later revisions as fixes for additional bugs in the same and closely related files get added. Very rarely does a patch add a new package, it just makes minor updates to an existing one. I think another factor might be the historical distribution model, mostly via CDs or DVDs. What a patch usually is, is a partial overwrite of one or more packages, (i.e. of _some_ but not all of the files in a package), possibly accompanied by additional scripts to do smarter things like merge changes into configuration files. Along with that, the patches applied to any given package(s) are recorded, etc. I suppose the existing SVR4 pkg mechanism, give or take additional metadata added to each packages pkginfo file, is itself capable of other models, such as one where one always replaced entire packages. However, this would not speed downloads (bigger) or updates (more files to update), nor would it produce as much simplification as you might think, since a patch would still have to exist in the sense of total replacements of all of the packages that had to be updated together, plus any scripts needed to do tricky stuff. And the patches give you one thing by default that wholesale package replacement does not: the option to back them out. It's been worse in the past, but right now, I suspect that well under 1% of patches that successfully install, are such that one might need to back them out. But it still does happen occasionally. Also, patches as they are now (if they were a bit more careful about spelling out _why_ a reboot might be needed) potentially involve less reboots since they're replacing less files than whole package replacement. And keep in mind that a lot of this stuff is done the way it is for the sake of the sort of customer that probably schedules _any_ down time or maintenance well in advance. A lot of this isn't unique to Solaris; I think a number of other (mostly non-Linux) commercially distributed OSs distinguish between a package and a patch in some sense or another. Some of the reasons adding a patch might fail and the associated messages are described on the patchadd man page. Back when it was a (slow) script rather than a compiled program, the code also listed the meaning of all the return codes from patchadd. Since I can't find the source for the binary patchadd on src.opensolaris.org, I suspect it hasn't been opened (yet?), so I don't know whether those have changed. So I don't necessarily have a problem with SVR4 packages; I think they can be with perhaps additional metadata made quite capable of doing whatever is needed. I wouldn't rule out changes outside of the packages themselves. And I don't necessarily even have a problem with some form of patches as a concept that builds on the concept of packages (which is pretty much the case now). I _do_ have a problem with the implementation of patches and of patching tools, although I haven't had an occasion to use the latest patching tools, so I don't know if they don't stink as badly as the old approach of reading all the READMEs to determine the dependency order manually, and running patchadd (redirecting stdout, stderr to a file, and if you're smart, running lockfs -fa between patchadd commands to ensure everything got committed to stable storage) on a batch of patches in the appropriate order. There are things such as "pca" available free from outside of Sun, that can make patching much less painful (google for pca patch will find it as the first hit). The most structural problem with patching as it is now is if one has a less-than-full install, applies some patches, and then adds a package that one or more patches would have updated. Getting that package up to date in a manner consistent with how it would have been if it had been installed along with the rest of the system and all the patches then applied, can be very tricky. Smarter patch analysis and installation tools could probably identify those situations and allow a re-install of the patches for only the package(s) that needed them. Indeed, I'd argue that the patches could actually build a log for each package they update that isn't installed, so that as soon as it was installed, one would be told of the list of patches needing to be re-applied in the correct order (which should be possible automatically given an accessible _patch_ repository). And I think that friendlier package updating tools (over and above mere patching ) are also badly needed. The whole _official_ repository thing is interesting in some ways. It sounds great to just point pkg-get at a hypothetical official repository, and do pkg-get -u -f and wait awhile. But I don't think that's quite enough to do it right; sometimes certain groups of packages need to be installed together; they might for all practical purposes have circular dependencies. Such an approach to updates might offer no guarantees about how runnable the system might be at any given point in the updating. There's always the issue of the explosion of testing scenarios the more different ways and combinations of ways someone might update their system. And there's a tipover point somewhere, where kernel+library interdependencies, plus trying to have documentation that matches what's on the system, plus dependencies on newly introduced commands, plus... well, you get the idea...mean in effect that you've updated yourself all the way to what ought to be regarded as a new release. It's a lot simpler and more stable if that's a formal entity, such that there can be a clean start on testing, documentation matching what's included, etc. And mapping patches to a whole package update approach is also tricky. Let's say that you have two patches that update a package, independent of another. You now have four possible versions of the package: original, patch A applied, patch B applied, or both. Having a repository have all those is unreasonable. Having it only have the most up to date for the release may sometimes not satisfy all possible dependency situations. It could be done, but it couldn't be done anything like automatically, IMO. There are however cases where new packages get introduced for updates within a release. And there is an update mechanism for that, although it's IMO slow, ugly, hard to test, and often not as clean as a fresh install might be. The Live Upgrade approach (more or less: automatically building a replacement root/usr/var/whatever on an otherwise unused filesystem that becomes the new boot filesystem once it succeeds, and migrating config files as appropriate) is at least a lot safer (can always fall back) and can run with nothing but a performance impact while the system is in production. But there are times when it turns out to be perfectly ok to (starting with release X mm/yy) take packages from the next update, along with any new or updated dependencies, and add/update them manually onto the existing update. There are probably more such cases than are commonly recognized. Heck, I can think of more than one case where patch README files said to get a package from at least such and such an update and add it; and I _know_ there are more cases that sort of thing is never explicitly mentioned, but works out just fine. So I think that for any given release, it might perhaps not be impossible to have a repository based approach, but it would have to be supplemented by additional information _outside_of_ individual packages that caused packages to be aggregated as needed, additional scripts to be associated with those aggregations as needed, the process of applying a set of updates to (if applied to a running system rather than to an alternate boot environment as Live Upgrade does) be capable of being paused at various points, continued after some point in it that requires a reboot, restarted automatically in event of certain failures, etc. In effect, a repository based approach would have to provide all the benefits that the present version[/update] plus patches approach provides, be every bit as reliable, and a lot easier and more transparent. To merely do as some Linux distro does in terms of update management may well be far short of sufficient; the expectations of the established installation base are vastly different (stability and reliability; nice if it were easier, but it's always sucked anyway, so at least that's job security (back in SunOS 4.x (BSD based), patch installation was 100% manual, and sometimes even mildly technical (knowing C helped get a kernel patch installation right). So however bad the patch mechanism is now, what was before it was much worse, in fact nothing at all - not that that's an excuse!)). All in all, it's not as if there were no reason for how things got the way they are, nor why a simple replacement of one overall approach with another existing one (regardless of underlying package format) might not be adequate. It's a heck of a lot harder IMO than just saying "make it happen". NOTE: I probably got a lot of details wrong, 'cause my only part with any of this is to use it. I've built the odd package for myself, never built a patch (I doubt anyone outside of Sun has tried to use their patch mechanism). And all my exposure to how things got this way was just to read Usenet comp.unix.solaris, various docs, and more recently the Jive forums (equivalent to various mailing lists) on opensolaris.org; along with using and seeing other people use these things. But notwithstanding that disclaimer, I think I've at least made the point that while a better approach certainly ought to be possible, it's almost certainly nowhere near as simple to achieve as many people seem to believe. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
