On Fri, Aug 28, 2009 at 1:19 AM, Robert Milkowski<[email protected]> wrote: > Martin Bochnig wrote: >> >> On Fri, Aug 28, 2009 at 12:53 AM, Philip Brown<[email protected]> wrote: >> >>> >>> A long while ago, I brought up the unpopular point, that the real problem >>> with patching, is not "SVR4 patching is broken", but "Sun's patching >>> teams >>> make poor choices about how to structure patches(and group packages)". >>> >>> I was basically shouted down, for daring to criticize Sun, or the >>> direction >>> IPS was heading in. >>> >>> No one bothered to confirm or deny whether what I said, was *true* or >>> not. >>> >>> Here's some hard data to prove the truth of the point I was trying to >>> make. >>> >>> My reason in bringing this up again, in this forum, is to ask the IPS >>> team >>> how they plan to make IPS magically fix this sort of problem, when it is >>> caused by the sun packaging/patch teams' PROCESSES, not lack of >>> technology. >>> >>> My guess is the reply will be , "disk space is cheap, so just do full >>> installs everywhere". But I'll state ahead of time that in my opinion, >>> this >>> is not an appropriate response to customers >>> >>> * * * * * * * >>> >>> The real-life problem: >>> (and note that, being real-life, the problem description is somewhat LONG >>> :-) >>> >>> >>> I'm looking to patch a bunch of solaris 10 sparc servers. >>> They have a "server oriented install" set of packages. To give some idea >>> of >>> the scope of the install: >>> >>> # pkginfo|grep SUNW|wc -l >>> 592 >>> # (whereas a full install, would have 2000+ packages) >>> >>> They have SUNWxim installed. Even though a local X server is not >>> installed. >>> >>> Because, being a university, our customers may very well wish to run >>> UTF-8 >>> locales for some programs, remotely. >>> That means we have things like >>> system SUNWeuxwe UTF-8 X Window Environment >>> installed. Which require SUNWxim. >>> >>> (I also vaguely recall that some java things complain without SUNWxim >>> installed, but i could be mistaken) >>> >>> So far so good.. but now I want to install a recommended patch cluster. >>> Which includes patch 121975-01 >>> >>> >>> patching 121975-01 FAILS. Because it depends on 121975-01. >>> patch 121975-01 fails, because SUNWdtdte is not installed. >>> >>> But we dont WANT SUNWdtdte installed! That includes stuff like dtlogin, >>> and >>> all kinds of other cruft that dont belong on our servers! >>> >>> >>> SUNWxim does not depend on SUNWdtdte. Therefore, a patch for SUNWxim, has >>> no >>> business pulling in an implied dependancy on SUNWdtdte either. >>> But it does, and the patch fails without it. >>> >>> That fairly tightly fits my own personal definition of >>> "broken patch creation policies/procedures". >>> >>> So, how is switching to the "better technology" of IPS, going to solve >>> this >>> problem of broken patch creation process inside of Sun? >>> >> >> >> >> Hey Phil: Very easy! As no "--no-deps" is "supported", your scenario >> would not even be possible anymore, not at all. That's the solution >> (really). >> > > As Shawn and Bart posted today --nodeps will be supported via 'pkgrecv > --nodeps ...; pkg install' which is fair enough and does make sense. It is > actually supported even right now - it is just that it is too ceymbersome in > a current form for an average sysadmin. But Shawn expressed clearly they are > open to suggestion to make it easier and even proposed a solution which > sounds really good. > > Philip - the answer is relatively easy - as there are no patches in IPS. If > there will be a bug fix for SUNWxim it will be provided in form of a new > SUNWxim package (different timestamp or version) so you will just upgrade a > specific package. Even better - as not necessarily all files in a new > package will be different pkg will (it already does) fetch only files which > changed making an upgrade even quicker. Providing bug-fixes in form of a new > package version has been common on many other platforms like Linux and has > been working really well for them. The only main issue has been lack of > reliable rollback with such an approach except for installing old package > again which not always is the best option. In opensolaris thanks to BE you > can actually upgrade your system (or selected packages) on a new BE which is > a clone of current OS and reboot to it when you ready - if you want a 100% > (kind of) guarantee to rollback the change you reboot to old BE - I really > love it and I've been using it for some time now. > > > > -- > Robert Milkowski > http://milek.blogspot.com
Ok Robert, Shawn, Dave and Bart. I'm more or less convinced now. Congrats to IPS) rgds. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
