On Oct 12, 2007 7:48 AM, Richard L. Hamilton <rlhamil at smart.net> wrote: > > 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
Definitely the first. One annoyance inherent in systems that deliver new versions of packages is collecting together the set of updated packages; having a patch being a bundle of all the bits necessary to apply a particular transaction is very convenient. > 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. Indeed. I've been looking at (working on would be far too strong a term) something that might be called pkgupdate, that simply does the logical equivalent of pkgrm+pkgadd. I hate to think what horrors the patch system might be perpetrating to perform tis simple operation. > 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. A transactional unit of packaging, if you like. And like a transaction, the constituent operations succeed as a whole or are backed out. > 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. I believe that the dependency should be on the package versions. That way there is only the one attribute to track. (This would allow alternative update schemes where admins built their own patches from the available updates to work alongside official patches, amongst other things.) > 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) Agreed. > * 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 Maintenance updates reborn? Service Packs? > 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). Well yes, some strange things have been whacked in there.... -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
