Dave Miner wrote: > [...] > 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.
Basically the software that a user installs in his home directory is not part of a specific system. It's part of the network. So it's on vain to register it on a specific machine. It must be accessible wherever the user is roaming with his home directory. So the home directory itself might be a proper place or an LDAP directory ... If the home directory is on an nfs share the system admin might not be able to access it. The user might use the machine never again, and prefers to use a different one to deinstall his software (or move it to the trash can on a Windows box). > Further, this proposal raises many more questions about the ability of > the package and patch tools to present a coherent view of a system, In this context they can't, and I don't think they should try. Only software that's "owned" by a specific system should be part of this view. Software that is "owned" by a user should not. > 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. The system must not depend in any way on software that it does not own. > 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. Validation cannot be done (fully) at installation time. It has to be done at runtime, if at all. A user will be happy to install a software on, say, Solaris 10, and then later try to run it on Solaris 9 (or FreeBSD, or whatever) > 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. Yes! just my 2 cents Christof >
