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.
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. -jhf- Mike Kupfer wrote: > Making the package tools available to non-root users is very cool. Thanks! > > I'm wondering whether the following scenario might need some additional > support from the tools: > > 1. user U pkgadd's application App in $HOME. App depends on library > Lib, which is currently installed at the system level, so the pkgadd > succeeds. > > 2. root pkgrm's Lib for some reason > > 3. user U runs App, which fails with a (somewhat obscure) message about > a missing .so > > I suspect that it's not feasible for the pkgrm to detect in step 2 that > App depends on Lib. > > Is there some easy way for user U to determine that (s)he now needs to > install the Lib package in $HOME? > > mike >
