Christopher Kampmeier wrote: > > Limitations of SVR4 from an ISV's perspective: >
Interesting "new" perspective on things. I have some comments :-) (and questions!) > * lack of user-based install for applications > * lack of multi-install for applications > * lack of reusability on other OS platforms > * many of the other limitations already stated > ... > * Multi-install isn't just the ability to install two or more instances > of the same named package. More importantly, it's the ability to install > and manage multiple independent graphs of application packages on the > same OS instance. Do you mean full dependancy trees of differently rev'd stuff? As in, /opt/foo_a that has glib 1.a, gtk 1.a, libpango 1.a, and then /opt/foo_b, that has glib 1.b, gtk1.b, libpango1.b ?? Are you actually telling me that IPS "solves" this? If so, i would be interested to see a reference on this. > Sure -R or --root with RPMs can be used to achieve a > similar result, but those options weren't designed with the use case of > managing separate application install images on the same OS. They were > designed with the expectation that there's an OS as part of each "root". I would have to disagree here. The -R stuff works fine for this purpose, so long as your app-level pacakges, dont have OS packages as dependancies. It's not about the packaging system, not supporting it. It's more about the *applications* not supporting it. The *applications* have to be both compiled, and packaged, in a way that supports installing to multiple locations. If they are not, then no packaging system in the world is going to solve this issue for you. If they are, then SVR4 packaging can already support what you need. > * User-based install: Apart from the developer use case, we often find > that deployed application installations are managed by app admins that > don't have the same degree of privileges of the OS level admins. There > are fundamental issues with SVR4 in trying to grant appropriate > privileges to app admins. I think that this is an intrinsic conceptual problem, rather than a "SVR4" problem. At an enterprise level, there are reasons to **not let users install software packages**, depending on what the software in question is. For the non-harmful ones, the -R option can also be a solution to this, if "pkgadd/pkgrm" was trivially modified to run/not run based on, "does the user have permission to modify the 'contents' file", rather than a blanket "is the user 'root' or not"? There are additional fairly straightforward, easy code changes that could be made to pkgadd, to make it more userfriendly for these sorts of purposes. But even with zero code changes, it is currently already possible to allow a user to run, via RBAC or sudo, "pkgadd -R /var/userroot *" > * Reuse on other OS platforms: An attractive aspect of IPS is that we as > an ISV will be able to package our apps once, reuse those packages > across OS platforms and benefit from the repository-based capabilities > across the board. Ummm... there are multiple cross-platform, long-time established packaging systems, that are network aware (such as apt-get! :-) Or marimba. or....) Why dont ISV's just use one of those, if reuse across platforms was so important to you? This seems like a somewhat mythical argument to use IPS to me, since it has already been "solved" elsewhere. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
