> Dave Miner writes: > > My contention, and I think others who've spent a > lot of time looking at > > it would agree, is that the present architecture is > fundamentally > > flawed. Building patches as a layer on top of > packages, and then having > > a packaging system which is unaware of that layer > above it, is > > untenable; we've managed to prove that pretty well > by experiment on > > y'all over the last 15 years. So I don't see how > you can separate the > > two and say that "packaging is fine" and "patching > is broken". They've > > had an equal hand in creating the mess that exists. > > I'd separate them by refusing to ship patches, and > shipping only > upgraded intact packages -- perhaps frequent > Update-like releases. > > I agree that the patching scheme is untenable, I'm > just not so sure > that says anything about the unadorned SVr4 packaging > underneath. >
The question in my mind is what value patches add? I would suppose that might be: * updating sets of closely related packages together * additional handling of transition from older to newer versions of a package * other oddities, or repairs to the state info of the packaging system itself (due to a bug being fixed), that are outside the scope of packages; another example (for which patchadd doesn't even apply) is firmware patches I suppose there's nothing fundamental about SVR4 package format that precludes packages from being made smart enough (and enough files tagged as "e" or "v" in pkgmap and/or those types are handled carefully enough) to handle package replacement without the need for patches to do anything additional on that score. However, I would also suppose that the concept of a patch as a quantum of updates (whether a set of package replacements that need to be made together, or some actions outside the scope of packages, or perhaps both) might remain useful. I don't know whether dependencies among patches, or simply patches being dependent on the prerequisite versions of packages for the versions they're updating to, would be easier for the end user (or updating tools) to handle. Heck, there are still lots of arguments about an updating philosophy; anything from "if it ain't broke, don't fix it", to "be proactive; install all recommended or security patches, or anything else that the vendor support folks might suggest, if only to deny them the excuse to stall". And then there's the granularity some people like: notwithstanding that recommended patch clusters aren't necessarily tested as a unit, some consider it more stable (or at least more uniform) to simply throw them at everything (not to mention that they take care of dependency order, and throwing them everywhere eliminates a lot of thinking and keeps things somewhat more uniform). Then there are those that think if it isn't an emergency, we really ought to just wait for the next update release and do a LiveUpgrade (except that most existing systems don't have any space set aside for that). I think that: * SVR4 packages aren't inherently incapable of doing what's needed, although they may need to be smarter in terms of their pre/post install/remove scripts and such; and the tools also need to be smarter (but see below) * any further rethinking needs to encompass reliability as well as ease of use, and result not only in new or updated tools, but in a recommended updating strategy (or selection thereof) with hard evidence as to its benefits to support it, as well as some awareness as to what combinations of updates are most likely to have been tested together I do have one reservation about SVR4 packages: the text format of pkgmap(4) and /var/sadm/install/contents (yes, I know people should be using pkgchk -l, but the reality is there are a lot of scripts out there that use grep or [ng]awk on /var/sadm/install/contents) makes names with delimiters (like spaces) in them require special handling, and certainly slows things down (compared to a true database of files/packages, which might even allow unrelated patches to be installed or packages to be updated concurrently). However, a binary format has both compatibility problems (unless the old way continues to be supported) and recovery problems in case it gets scrambled (eventually, zfs root and promotable clones integrated into updating mighit make all that irrelevant, but for now, binary files still tend to scare traditionalists, and not without reason). I don't think that's a show-stopper that can't be worked around (the characters in file names issue is worked around now, but it's ugly IIRC; and there have been those expressing interest in improving performance), but it is something to keep in mind. On the plus side, if packages needed to contain additional metadata, there's nothing I know of precluding adding additional parameters to pkginfo(4). This message posted from opensolaris.org
