site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com <SCENARIO> </SCENARIO> Couldn't this be worked around by messing with the database? -- Stephane P.S: The switch from ppl to dob is strange in this case. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... On Jun 26, 2008, at 10:35 PM, Luke Bellandi wrote: I heard somewhere that you guys implemented home-directory (user domain) install for Leopard. That's great! ;) I'm curious from an academic standpoint about a scenario like the following: [1] I distribute a package that allows both User and Local domain installs into ~/Afolder/. [2] I deploy v1 of this product in the local domain of a computer with 10 user accounts. [3] v2 of the product comes out, and I don't install it in the local domains of the machines in the lab, but 5 of the 10 users install it in their user domains. STATUS: Given that the domain search order is [User->Local->Network-

System]

Those users who installed v2 in their user directory will get v2 of the product while everyone else will get v1. That seems reasonable. [4] v3 of the product comes out, and I *do* install it in the local domain on the machine. STATUS: Now those users who installed v2 of the product in their home directories are behind the curve because of their explicit user-domain install. They won't be running against the v3 installed in the local domain. So -- there's nothing wrong with that scenario. Functionally it is completely correct. In the real world, however, you can imagine the computer-lab scenario where you've got a system-administrator who wants to keep certain products up to date and installed on the local machine and prevent users from overriding them. How can that be accomplished? While it can be done, it's usually a bad idea to "sudo" and go mucking around in other users' home folders -- though that would seem to be the only "solution" in this case. Or do people take the stance that this is a situation where we give people "enough rope to shoot themselves in the foot" with? I.e., if users do this and trump the local domain install, then so be it? Stupid question probably but from what I guess, this is not an application that gets installed but maybe some training materials or templates. Couldn't it be possible to go with the bad way (root messing up with the users directory) and sweeten it with an information message stating that the material is still available and has been updated? The issue with this is that this assumes the user has an admin password (or you want to use ARD to help with that). Maybe this boils down to a request for more flexibility in the way domain searching is done by the system? I'm interested in comments from folks at Apple of course, but also others on the list as well. Considering that domains are a 10.5 feature only, this would mean the package receipt will be in the database. This email sent to site_archiver@lists.apple.com