On 10/3/07, Dave Miner <Dave.Miner at sun.com> wrote: >> existing projects. I note that in the case of SVR4, the source has been > open for 18 months, yet only Peter Tribble has submitted any > contributions towards improving it (and they're much appreciated!). I > find that quite disheartening, and am somewhat mystified as to why the > widespread recognition that there's a need to improve things hasn't lead > to energy being put there.
To this day, I haven't seen anything with SVR4 packaging or pkgadd that I find painful to deal with. Blastwave and other work that I have done in the past has more than proven to me that a bit of infrastructure around SVR4 packages can give user experiences similar to those found on various Linux distros. My biggest complaint in this area is the slowness of various operations, but for the most part that is manageable. When it's not - that's an argument for Flash and Live Upgrade. I was eagerly awaiting other code to become available. Those areas initially included live upgrade and flash archives. I'm not sure if flash is encumbered or not, but live upgrade is. I'm not holding my breath on either. Since experiencing Solaris 10 patching, I've had significant interest in working on patchadd (pdo). In particular, I have an extremely hard time making sense of the output from the command and would like to improve it. That brings up an interesting situation, however. Patches aren't terribly popular on OpenSolaris. They are essential on Solaris 10. Just because a fix gets into OpenSolaris doesn't mean that it makes it into Solaris. My interest in fixing patchadd is so that the dozens of sysadmins that rely on my work can work more effectively when managing Solaris 10. If I could get patchadd to work better in OpenSolaris, it would seem that it would be a shorter putt for Sun to get a better version into Solaris 10. Perhaps that is misguided optimism. For those at Sun that don't see it this way (from my viewpoint, no one at Sun sees it my way on this issue) pdo.c seems to be seen as an attractive nuisance[1]. If you look at it from the standpoint of "this is dead code because we have new stuff coming," I can see the point. If you look at it from the standpoint of it looks like it is a minimum of 2 years before the replacement is supported by Sun, it seems as though there is plenty of opportunity to clean this up. 1. http://www.opensolaris.org/jive/message.jspa?messageID=159151#160042 I miss the days of being able to translate patchadd return codes to something that means something. It was a PITA, but it was a million times better than: 0 Packages from patch XXXXXX-YY are not installed on the system 1 Packages from patch XXXXXX-YY are not installed on the system 2 Packages from patch XXXXXX-YY are not installed on the system Double spaced? WTF is the deal with counting the lines of output? The first time I read this there was one line of that type of output. I thought: "If zero packages from the patch weren't installed they all the packages being patched must have been installed, so why didn't the patch get installed?" It wasn't until I saw output that counted up to 5 or so that I realized it was counting the number of lines. This is just one example of the awful output from the command. It should be an easy fix to at least make the output easily parsed. At the simplest level, I'm not even talking about parsing with awk - I wouldn't be nearly as annoyed by this command if it simply used unambiguous English. If I'm going through the effort, however, I would aim for parsing with awk. That is one itch I would scratch, especially if I felt that there was a chance that it would turn into a standard patch to Solaris. Otherwise, you're right - it would be an attractive nuisance. > Ultimately, while I've chosen to provide a vote in favor of this > proposal, it's only because philosophically I don't feel it's my job to > tell someone they can't pursue something in OpenSolaris. However, I > hope you and the others who might choose to work on this project will > give serious consideration to not going forward with it and putting your > energies into IPS or Caiman instead. We could use the help. This is my primary reason that I felt that the proposal should be supported. Unless something really bad happens with IPS, I expect that it will be the way to go. However, as I'm looking at IPS it would be good to take a closer look at something else that members of the community feel meet the needs of OpenSolaris and by extension, Solaris. I expect that there will be cross-pollination that will benefit the end product and the individuals involved. -- Mike Gerdts http://mgerdts.blogspot.com/
