Multi-User Install Concerns

Below are some thoughts regarding integration between a system-wide updater and the future Eclipse update system. Some of it may be biased towards Linux distribution mechanisms but that can be changed where necessary.

One thing we had discussed at the Ganymede_Provisioning_Workshop was the idea of injecting dependencies into a system-wide management database (ex. the rpmdb on RPM-based distros). While this may help from a system administrator point of view, it breaks the semantics of how the distribution works. This is sort of hard to explain, but take this example:

• distro X decides to remove gtk2 (hey, it's an example ;)
• since distributions most often operation within a contained universe, tools like repoquery can be used to determine all of the packages that, in this case, gtk2
• if SWT was not in the distribution itself and there were no other users, the distribution may assume it is safe to remove gtk2
• if we were "materializing" dependencies from Eclipse bundles (SWT in this case) on native bits and injecting them into the system management db (ex. rpmdb in this case), we would be doing nothing to prevent distribution-wide decisions such as this
• the only place this kind of dependency creation would be useful is at the system level but that is not solving the broader problem

Disable updates completely

This is obviously not really ideal but may be an option some ISVs consider.

Agent talks to system-wide updater

• this is an in-app/a per-app update scenario and not really a good fit for systems that are updated centrally
• use Eclipse UI exclusively
• communication between system-wide updater and Eclipse UI
• interaction all done through Eclipse
• we would need to make the system-wide updater ignore Eclipse stuff
• the is how most "end-user" (ie. those that just download the zip) Eclipse installations are managed today

Eclipse UI + system-wide updates where possible

This is my ideal situation ---

• pull from system-wide updates when available, upstream otherwise
• User decides to install something. Example flow:

   already on system?  ---YES---> "pull" from "local repo" (/usr/share)
           |                          \---> done
          NO
           |
           V
        in yum?        ---YES---> yum install (root passwd prompt)
           |                          |
          NO                        WORKED?
           |                          /\
           |                         /  \
           |                       NO   YES
           V                       /      \
   pull from upstream     <--------        ---> done
           |
           |
           V
   install to homedir

The first decision branch above would only occur in the situation where a user explicitly disabled something that is installed system-wide and then wanted to re-"install" later.

Things to consider:

• loader must know about multiple locations (pools, .db-like things (ATM, I forget what they're called))
• multiple .db-like things
• how are users made aware of system-wide things?
  • I think all things on system must be in system-wide "profile" and only not present in per-user "profile" if explicitly disabled by the user
• disable Eclipse updater for system-installed pieces
  • per-location policy
  • permission-based policy (ex. "can't write to it, don't touch it")
• need to be concerned about use cases such as:

time | V	system	user directory
	bundle1 v 1.5 installed
		bundle2 installed which requires bundle1 v 1.5
	bundle1 updated to v 1.6	now bundle2 has a broken dependency

• will we pull all dependencies recursively into the user's location?
• if we don't, then the situation above happens
• if we do, do we end up with a second entire copy of the whole platform?
• system updates (done by root/admin) can't modify users' home directories

Clear separation between user-installed and system-installed components

Same as above but all Eclipse-initiated installs are put into the initiating user's home directory regardless of whether or not they are available in another provisioning infrastructure for the system. This is the situation we have now in Linux distributions.

Modify system-wide updater to show/get updates related to what you're running

This isn't really relevant to the Eclipse case but it can be something to consider if one can influence the sytem updater.

• could be at app startup
• could be on a per-use basis
• would still use system updater infrastructure
• sort of orthogonal to Eclipse case