James, As I've thought about this over the past few months, my main concern always comes back to the impact on maintainability, and I'm not really satisfied with the answers we've come up with so far.
First, I'll acknowledge that the outline as written certainly accomplishes the basic requirement of providing a replacement for usage of tarballs or other relatively unstructured software distribution mechanisms. But I don't think it goes very far beyond that, and I'm not sure that's enough. As a system administrator, I necessarily reserve the right to patch/delete/disable/upgrade any software installed on the system, because that software can present a risk to my system or other users in terms of things like security and stability. The changes proposed here provide additional flexibility for users, but they don't provide any additional leverage to the administrator in dealing with the issues that are raised, and I think they must; they certainly need to at least provide an adequate foundation for resolving that problem later, should we decide it's deferrable. For example, I think it's necessary to provide a registry of the "software domains" on the system, so that the system administrator will have the knowledge of where package installation has been done available to leverage, and so that tools can be provided to take advantage of that knowledge. We can't say that Update Connection is the answer - that's one possible answer, but it's only appropriate for the Solaris product, and not for the general OpenSolaris community. I note that your suggested interface changes didn't say anything about changes to/integration with Update Connection to register "software domains". So it's not clear that such changes are even being contemplated there, and thus I think it's somewhat incomplete as an answer even within the Solaris context. Further, this proposal raises many more questions about the ability of the package and patch tools to present a coherent view of a system, because that's not what they do anymore. We grappled with this in the zones space, and really didn't come to a resolution, punting due to lack of resources and time pressures. "Consolidation" is a great story, but if the consolidated system ends up requiring the same (or worse, new) expensive third-party tools to manage the software as a network of systems, then it's far less compelling. We know we need to do a bunch of work to make the user's software maintenance experience on Solaris modern and competitive, and I'm disturbed by the thought that this proposal will actually increase the scope of that problem without making any steps in the direction of addressing it. I'm interested in some elaboration of the DOS concern. I can imagine some concerns, but I'd like to understand what you're specifically trying to prevent. I'm quite concerned that the statement about not supporting recursion of domains is in possible conflict with many of my comments above. Perhaps you'll elaborate on what you meant by that. Further into the details, I'm concerned about the downgrading of dependency and architecture validation - I can see reason to provide ways of downgrading it when necessary, but I do not believe this should become the default. Many of our complaints and problems seem to stem from insufficient use of these features as-is, and making them less used doesn't feel like the right direction in providing error-free installation of software. We must optimize for the usual case, not the unusual, and UBI with unresolvable dependencies or cross-architectures is most definitely in the unusual to my thinking. One other thing: I think there's insufficient attention paid to the ease of building packages. If we really want ISV's to use packaging rather than tarballs or their own scripts or third party installers, I think we need a little more than pkgproto, pkgmk and some man pages (the developer's guide is only barely beyond that, IMHO). We can perhaps say that's out of scope, but should be explicitly recognized as a hole in the story. Dave
