Christof Pintaske wrote: > 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). >
Sorry, that sounds like we're just trying to say ETOOHARD, and I don't buy it. For these cases, we can construct all sorts of cross-system solutions, perhaps using a directory service, as you sort of seem to allude to. Solving that would seem to be even more valuable, because then you can help improve TCO of a larger "system". >> 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. > Again, I disagree; did we suddenly decide that the network isn't the computer anymore? And how would I, as an administrator, find the software that has been installed? Write a big "find"? Why is it necessary to force that cost onto the customer, where it's definitely higher in aggregate as each customer has to come up with their own? >> 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. > That doesn't answer my question in any way that is meaningful. What is the threat that we're attempting to design against? >> 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) > You'd seriously assert that there is no value in attempting to point out to a less-sophisticated user that perhaps he's trying to do something that won't work and doesn't make sense? This is not an either/or proposition. Install-time checks in no way negate the utility or need for run-time checks, but just dismissing them is certainly disrespectful of a user's time - when you think/know something is wrong, you need to say so, not play passive-aggressive and let him get lost and try to figure it out later, where it may well be much harder to sort out. Try running a SPARC binary on x86 and see how easy it is to figure out what the root cause is - you have to know a bunch of things to deduce it. Most of the other failure modes from bypassing install-time checks are similarly obtuse. >> 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! > Well, at least we agree on one point ;-) Dave
