> 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) 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. I guess my thing is, Solaris isn't just POSIX/SUSv3 (which Linux isn't quite in the former or at all in the latter), it's also SVID3 (SVR4 specs), which Linux isn't even remotely. I don't see why the _option_ of per-account Linux-like personality or even more friendly Linux-like administrative commands as an option need necessarily alter that or disrupt the existing user base. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
