Another issue in the long term will be different operating system revisions and nfs-mounted home directories. If the user installs packages into their home directory for operating system revision X, when the user logs into operating system revision Y, will it work?
I think you'll have to keep the package information completely in user-space for that to work. You'll also need a method to indicate the target operating system revision and a method to segregate packages for one OS revision from another. I'd envision a GUI tool at the user level that would keep track of their own 'personal' packages that track updates, similar to update- manager. That would be very useful in the long term at a user level. On May 31, 2006, at 12:45 PM, 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. > > 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 > _______________________________________________ > install-discuss mailing list > install-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/install-discuss ----- Gregory Shaw, IT Architect Phone: (303) 673-8273 Fax: (303) 673-8273 ITCTO Group, Sun Microsystems Inc. 1 StorageTek Drive MS 4382 greg.shaw at sun.com (work) Louisville, CO 80028-4382 shaw at fmsoft.com (home) "When Microsoft writes an application for Linux, I've Won." - Linus Torvalds
