Responses below. Chris
Philip Brown wrote: > 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 > > ?? Basically, yes. Additionally, separate install images are necessary to simplify the process of maintaining the separate graphs. Intertwining the graphs in the same package database is a complex affair that we as an ISV don't want to foist upon users of our applications. Using tools such as zones, VM images and such are applicable in many cases, but in many other cases, these tools are overkill to gain the ability to isolate applications and their underlying dependency graphs. Many applications support the multi-install and user-based install requirements in a variety of ways - none of which depend on intertwining OS native packages within a single system package database. Unfortunately, based on extensive investigation, we have yet to find a solution to these requirements that is cross-platform and supports additional requirements such as ease of updating. IPS is very promising in these respects. > > Are you actually telling me that IPS "solves" this? If so, i would be > interested to see a reference on this. Sure, user images fill the bill quite nicely: pkg image-create -U -a sun.com=http://updates.sfbay.sun.com:10000 c:\sdk -U carves out an install image area in the c:\sdk location and tethers it to the package repository named in -a. The notion of "user images" is a fundamental premise of IPS. (Partly due to our incessant nagging on the subject within Sun). Additionally, the fact that a user can run the IPS command as non-root to establish and maintain discrete install images is aligned with our interests (maybe not aligned with yours, but it suits our needs). > > > 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. In our quest for a decent packaging and update/patch solution for our middleware products we spent time experimenting with the -R and --root options on SVR4, Solaris style patch tools and RPM. Since the -R option isn't explicitly positioned as a means to establish and maintain non-OS images, we started our experiments with some healthy skepticism. Although the basics of using pkgadd -R to establish an installed image of some middleware apps worked, as soon as we started trying to apply a patch, things broke because we hadn't represented at least a semblance of an OS install image at the -R location. Specifically, the lack of an INST_RELEASE file caused patchadd to fail. You can tell me that this particular issue isn't an SVR4 problem, but we as an ISV are looking for a solution to help us and users sustain our apps. Patching is part of the solution. Using SVR4 only isn't good enough for us. (It might be good enough for others, but not for us). This INST_RELEASE issue was an example that helped reinforce our understanding that SVR4 and the associated patch tools were not designed with -R being positioned for non-OS images. Were there other issues lurking beyond this example? Who knows, but I wouldn't be surprised if we had hit more. Each of the issues encountered could be addressed in a piecemeal fashion, but as an ISV, we never had a warm and fuzzy that the investment in this direction was going to be worth the resulting benefit. Especially when we also knew that SVR4 and the associated Solaris patching tools are not positioned as cross-platform. > > 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. In our world of delivering commercial middleware products we do these things all the time. They aren't issues for us. However, merely making our packages and the associated app configurations relocatable isn't sufficient. > > 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 *" Been there, done that. It has been years since the RBAC route was tried, but in our experiments we hit significant roadblocks in trying to meet our requirements. I'll defer to others to elaborate on those issues. > >> * 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....) apt-get isn't a solution by itself. It depends on an underlying package format. Unfortunately, the package formats that we analyzed were not readily cross-platform enough for our needs. Even the RPM-based OpenPKG technology, which we seriously considered, is cross-platform across Unixes only. Windows support? Nope, not there. Well, why not just take a different approach for Windows? If we had to do so, we would, but with the advent of IPS, we don't need to spend the extra money to do so. > Why dont ISV's just use one of those, if reuse across platforms was so > important to you? I can speak for ourselves: Because the broad array of approaches we've looked at aren't as cross-platform as you might believe and/or don't meet a bevy of other requirements such as being easy enough to patch and sustain and being open source-based (to name just a few). > This seems like a somewhat mythical argument to use IPS to me, since it > has already been "solved" elsewhere. We see our decision as an ISV to invest in the use of IPS as making good business sense in that we're taking advantage of an opportunity in which the timing of our decision and the advent of IPS are aligned quite well. Based on our practical experience, we haven't found another solution that meets as many of our requirements. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
