+1 to everything Peter says here. I'll add a few things though. SVR4 has some limitations -- and scripting is one of the weakest. IPS single greatest strength is that a package in theory is fully described by its metadata. (It turns out that this isn't 100% true, as post-reboot scripts in the form of special SMF manifests have become a way to "workaround" the lack of scripting in IPS.) Whether you love or hate the manifest format, there can be no doubt that self-describing packages are a wonderful thing.
In almost every other way IPS fails, with the sole exception that it works well *if* you are an end user who only ever installs software using IPS, and you follow strict rules about using the right repositories, etc. This does describe the majority of IPS users. But when things go south, or if you are an ISV, or if you install software via tar, pkgadd, "make install", etc., then IPS is a path to hell. One step outside IPS' creators utopian vision, and you will quickly learn to hate IPS. The other thing that seriously pisses me off is the way IPS was sold to Sun management. It was a solution to the problems raised by patches. Those problems did not need a new packaging system to solve them. The solution was to stop delivering (or even remove support for!) partial packages (the technical term for "patches" in SVR4 pkg parlance.) I.e. a "technical" solution was presented to solve what was really a "policy" problem. (The solution was to simply stop delivering/supporting patches.) IMO, it was a sleazy sales job, and the folks behind it ought to be ashamed. In my "ubervision" of illumos packaging, we would use IPS manifests (which have that wonderful self describing property), and different vendors can use them as source files for a variety of binary packaging formats. I know that people have figured out how to parse and process those manifests to create not just IPS packages, but also Debian (illumian & Nexenta do this), ISO (Joyent and DEY do this), and SVR4 (I have done this in an ugly proof of concept). This leaves the choice of "packaging" to the distribution vendor. Which is as it should be. -- Garrett D'Amore Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Tuesday, December 18, 2012 at 5:20 AM, Peter Tribble wrote: > On Tue, Dec 18, 2012 at 8:56 AM, Philip Robar <[email protected] > (mailto:[email protected])> wrote: > > I've noticed that there seems to be a fair amount of dislike for IPS which > > leaves me puzzled. On paper IPS sounds great and I know that some serious > > thought, engineering and math went into the design of IPS. I also know that > > despite the claims of SVR4 packaging fans that SVR4 packages have their own > > limitations--especially when it comes to patching systems. (Fortunately my > > own scars from my days of packaging software for Solaris faded long ago and > > only dim memories of those days remain. :-) > > > > I'm particularly curious as I know one of the engineers who worked on IPS > > and he's one of the smartest people I've ever met. > > > > Are the objections to IPS centered on its design or implementation, or > > both? Are the SVR4 fans blind to its limitations and/or ignoring difficult > > problems that can't be ignored in a business/enterprise environment? If > > there are any objective and reasoned writing or discussion on the subject > > I'd appreciate a pointer. > > Objections to IPS cover the whole spectrum - political, technical, and social. > > The way that IPS was introduced into OpenSolaris was plainly > unacceptable. Political machinations and secrecy abounded, and > community involvement was denied. The breakdown of trust and > sheer insult to the community would have made IPS a hard sell, > even if it had been technically sound. > > From the technical point of view, IPS is pretty weak. It's not too bad > (although still far too slow) for an end user. Implementation in python > limits minimization possibilities, and artificially ties an instance of python > to the OS. It inherits the fundamental flaw of implementing zones > via packaging, rather than keeping packaging independent of zones. > It insists on defining policy, rather than implementing the policies > defined by an administrator. It still has meaningless package names, > random package boundaries, and incorrect dependencies. By > embedding so much system knowledge into packaging (zones, > the way drivers work, services, etc) it is a huge barrier to innovation > and development in those areas. Being network-only limits its use > in many scenarios. It's also proved in practice to be far too fragile > - many of us have ended up with a hosed system that IPS refused > point bank to let us do anything with because of its constraints. > > There's also the social aspect, which in many ways concerns me > the most. To encourage adoption, you want to build the broadest > possible ecosystem. And that means getting others to build and > distribute software for your platform. The IPS repository model > is a huge barrier to entry, and many will simply refuse point-blank > to be involved. By contrast, simple file-based packages are easy > to build and trivially easy to distribute by any channel. As a > developer and software builder, I want to concentrate my energy > on building new software and facilities, rather than fighting with > packaging. The failure of IPS here is to understand that packaging > itself is irrelevant; it's the packages and their contents that matter. > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > illumos-discuss | Archives > (https://www.listbox.com/member/archive/182180/=now) | Modify > (https://www.listbox.com/member/?&;) Your Subscription > > > > > > > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
