On Sat, May 19, 2007 at 06:37:01AM -0700, Richard L. Hamilton wrote: > > There is a lot of cruft, like HOTLINE, ULIMIT, ORDER, > > etc. Why there > > is even a MAXINST parameter is a puzzle to me. > > One can have multiple instances of a single named package installed; > that happens for example if one is loads Studio 10 and Studio 11 > at the same time. For that to be practical, the packages have to > be relocatable and all but one have to be installed in a non-default > location. Non-relocatable packages would probably have MAXINST=1, > in other words. (relocatable means built not to depend on hard-coded > pathnames within the package, for starters)
Yes, but the question is, if you're defauled to a minimum of 1000, and you need to accomodate as many as possible, why even have a "maximum" instead of just tracking the number installed? > The format could be revised a little (in conjunction with an update of the > tools to handle it, even before new and better tools) to raise some of the > limits, or to introduce new metadata not subject to the old limits (which > depends on whether you're worried about breaking any 3rd party package > tools, if in fact any exist other than perl scripts that probably wouldn't > care). And hooks for additional pre/post install/remove scripts could > probably be added. So while the SVR4 pkg format may have some > shortcomings, minor revisions should keep it up to date. > > No existing alternative packaging system would work properly _as-is_, > because Solaris hooks zone setup (for example) into the packaging system > functionality, and maybe other things too. Of course, if one's premier > goal were simply to rip everything out and start over, it could probably > be done, separating out this stuff somehow, and probably complicating > or at least altering certain existing administrative tasks. But I think > something more comfortable for both new and existing users could be done > in a far less wholesale manner. Yes, I noticed the zone hooks. I see that the format's been extended, but it's still not "complete" because some of the cruft conflicts with what you'd want (like packages being able to obsolete other packages, instead of just patches having that effect. You may argue that that's not what's always desired, but having that feature is a useful and practical feature when needed). But my question was "why" not "what does it do". -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
