James Falkner wrote: > Yes, this was brought up by Albert as well. The deal with this is that > there is potential for abuse if we fail (or even warn). For example, > rogue user A can install a package into ~A which depends on every single > package in the universe. From then on, when anyone else on the system > attempts to pkgrm, it will fail or warn or go interactive saying that > "User A depends on this, are you sure?" - same goes for user A who > depends on a different (non-root) user's package. The concept of the > Domain-Path, combined with some semantics, will reduce or eliminate > the potential for abuse and also not require exhaustive searches > to see if you're about break something. Only those users' domains > who are in your Domain-Path will be searched for dependencies > during pkgadd/pkgrm. This means that any other software that might > depend on your is completely invisible unless you allow it in your > Domain-Path (also known as a "Friends list" or something of that > nature). This also means the root user does not look through the > entire system upon every invocation of pkgrm. >
I follow your argument, but I don't agree with it. The administrator would more than likely want to know that his impending action is in fact going to break something, so that he can pro-actively deal with the situation, either by not performing the action or coordinating with the affected user(s) in some way. To me, this is how your proposal might work in some large corporations: - I install Firefox 2 in my domain since the bundled version doesn't get updated often enough - Outsourced administrator blithely removes package on server with a library my Firefox install depends on, without knowing that there are any dependencies - Sometime later, I run Firefox, it fails. I'm smart enough to find the actual Firefox executable, run ldd, and figure out which library is missing; this is a bit beyond a non-engineer user. - I file a P1 trouble ticket asking for the library back - I get a call back from somebody in some distant timezone who I have to spend an hour explaining why this is a problem; ticket gets downgraded, maybe in a few days the library will be put back, or I'll be told, "too bad, that's not a supported application" - Eventually I decide it's quicker to go find my own library and then install it in my own "domain", though with our current packaging tools and lack of an easy-to-use repository other than Blastwave's, that's not exactly the easiest thing to do, either By actually searching the known, registered domains (assuming we did something like what I suggest to collect them), the administrator, or even the tools, could let me know what happened. If they went ahead with the removal I'd still have the problem of resolving the dependency myself, but at least they would have made a deliberate decision, rather than an accidental one, and we might have avoided the trouble ticket runaround and per-incident charges that result. > The way that users will discover broken dependencies is by using > the existing 'pkgchk' utility whenever they want to see if someone > broke them. They can also ask users who they depend on not to > break them, by adding their domain to the required user's Domain-Path. > Maybe I'm dense, but I don't see that pkgchk has a way to answer the dependency question, though you asserted it here and in the original proposal. Are you intending to add it? Dave
