On 5/13/07, Vasiliy <vassun at gmail.com> wrote: > Hi Mike, > > - Return codes, I raise this question about 6 months ago > explaining that single return code does not work for set > of patches and asked to discuss and to see what API needed > - I receive no replay.
I've seen others raise the issue of not having it and had never seen any reply from someone with access to the code that provided any sort of hopeful interaction. You seem to be the first and I missed your initial query. :) I would be quite happy with less verbose output that is parsable. That could be as simple as: patch-id:short code:detail For example, a system with 118833-24 already installed that is trying to install 118822-30, 118833-36, and 125100-06 should give output like the following. 118822-30:Obsolete:Obsoleted by 118833-24. 118833-36:Installed:Immediate reboot required 125100-06:Error:Reboot required before installation More detailed logs should also be available. It should be possible to specify that the machine readable output go to one place (stdout or a file) as well as more detailed output (stdout or file). Obviously, having both going to the same place is not terribly helpful. > - Patchadd -t was introduced as internal option for QA > to let them reprogram some test. And it is not working > with zones - never intended because it is passing pdo > and directly call old script instead. That's fine, but it is very useful. Customers often times need to do the same types of things that Sun's QA needs to do. If I'm patching hundreds of servers, I need something that can summarize the results. This shouldn't be hundreds of lines of perl to account for the different output that different releases of the patching tools generate. > - Text output - see my answer on return codes, I thought > XML may be good, but it seems it is not really needed. No > replays. xml is fine (preferred) if I am programming in Perl or possibly C. If I am writing ksh scripts, xml is pretty tough to deal with. > - Unfortunately pdo was not picked up by higher level tools > yet and so they use old kshell script. Try patchadd directly > (patchadd -M dir) without -t and i should work faster. I need a tool that generates simple output that I can put in front of an auditor. The output needs to be concise and consistent. If you don't understand why the output of patchadd -M doesn't meet this requirement, I will be happy to detail it. > - Prepatch scripts must be used only for special cases > very rare. Currently they are overused, unfortunately. Are you saying that the existence of a prepatch script is what determines whether the patch README says that it is installed in single user mode, reboot after install, etc.? > I am author of pdo.c - it was programmed from zero in four > months and I have also new pdo with recursive patching and > new Solaris upgrade algorythm, will be nice if someone pick > it up after me. I have no idea that it is not opened - > remember I had special thread about how pdo works etc. But > I do not even know who made that desicion - not to open this > code and why it was made. May be it is too complicated? I is > very funny to have my full comments in that thread and don't > have code itself... In looking through http://opensolaris.org/os/community/install/, the only file that looks like it might have it is the SVR4 packaging tools source. I don't see it in there, however. It's good to hear that this seems to be unencumbered Sun code. Perhaps Sarah, Dave, or Bart could help to get this code out in the open. (I mention them because they are listed as Installation and Packaging Community leaders and I regularly see them on opensolaris lists. The other names don't sound familiar.) Mike -- Mike Gerdts http://mgerdts.blogspot.com/
