Community
Participate
Working Groups
This work item has been created as an umbrella bug report for all items pertaining to the "Improve Shared Install Support" plan item.
(In reply to comment #0) > This work item has been created as an umbrella bug report for all items > pertaining to the "Improve Shared Install Support" plan item. Scott, some time back I discovered a problem with using a bundle pool, looks like the concepts of "bundle pool" and "roaming installation" are mutually exclusive, is this still true, and if so can we fix it as part of this effort? My use case here was this installation - <dir>/bundlePool/plugins and features - <dir>/windows app/launcher.exe and necessary (meta)data only - <dir>/linux app/launcher and necessary (meta)data only TIA, Ciao, Helmut
The main use-case I'd like to see is the ability to have a single shared bundlepool, but allow configurable sets of features on a per-user or per-project basis. Using p2 proper (without dropins) it seems the only way to do this is either: 1) Have a central eclipse with everything installed into it. 2) Have a central eclipse with nothing installed in it, and each user having a configuration with all their required features installed locally. With 1 you can end up with: feature / action bar / menu bloat, as well as performance degradation caused by badly behaving plugins. Users complain that eclipse is too big and unwieldy. With 2 you waste disk space (and make initial user setup hard) as each user installs plugins locally, and must explicitly choose the set of features to install using the p2 UI. Ideally we would have a mechanism whereby bundles are installed centrally, and a default set of features can be chosen by a project lead. Users who want additional features can install them manually and/or remove features they don't want. This is currently achievable using dropins (bug 305642).
Fedora currently package and distribute additional features as dropins: http://fedoraproject.org/wiki/Packaging/EclipsePlugins Perhaps a solution that weens them off dropins would be a good benchmark for shared install success.
Fedora scenario: * Fedora deploys Eclipse using RPM. * RPM has the ability to check if the system has not been compromised by comparing the state of the installation with the rpm. * RPM is not able to run custom commands (like p2 director) and fail graciously. * Currently it is a dropins based solution. * Fedora does not care about installing plugins via P2 UI in admin mode, because it causes the RPM security check to fail (the installation changes without rpm awareness). * Fedora is interested in allowing users to install some plugins using P2 UI in their home directory. Current solution: * Dropins based deployment Ideal solution: Fedora ships rpms that are pre-validated and known to work together. Dependencies are solved through rpm dependency mechanism. It would be good to assemble the "master" eclipse installation from those rpms and may it superior to all other configurations.
I think the root cause of p2 doesn't suit for rpm and dpkg scenarios is simpleconfigurator implementation. P2 also wants to update the bundles.info for the eclipse base after installing/uninstalling software, however for linux package manager(rpm/dpkg) their major task is putting the files on the disk like what software publishers want. rpm/dpkg wants to keep the files installed by them are not changed, no way to know whether it's changed by user or post-install script if running director after putting files on disk. A graceful way might be creating a new configurator implementation(say as advanced configurator), it can read the configuration files from the conventional locations(such as /etc/eclipse.rc/, ~/eclipse.rc/) or specified locations. Those configuration files can help p2 recognize the bundles information, then create a cached list in user home. (In reply to comment #4) > Fedora scenario: > * Fedora deploys Eclipse using RPM. > * RPM has the ability to check if the system has not been compromised by > comparing the state of the installation with the rpm. > * RPM is not able to run custom commands (like p2 director) and fail > graciously. > * Currently it is a dropins based solution. > * Fedora does not care about installing plugins via P2 UI in admin mode, > because it causes the RPM security check to fail (the installation changes > without rpm awareness). > * Fedora is interested in allowing users to install some plugins using P2 UI > in their home directory. > > Current solution: > * Dropins based deployment > > Ideal solution: > Fedora ships rpms that are pre-validated and known to work together. > Dependencies are solved through rpm dependency mechanism. It would be good to > assemble the "master" eclipse installation from those rpms and may it superior > to all other configurations.
(In reply to comment #5) > A graceful way might be creating a new configurator implementation For a while now I've been thinking the same thing. IMO RPMs/dpkgs can ship bundles.info "snippets" and then this new configurator (should we call it DistroConfigurator?) would aggregate them at startup. We'd need to have a switch to the director to create these snippets instead of the entire bundles.info (and use the director during RPM/dpkg creation). Alternatively, we could just do a diff and ship that. We'd also likely have to modify the director or the UI so that it does the same thing when users install things into their personal area. Startup would then be an aggregation of the system-installed things (I'm envisioning /usr/lib/eclipse/bundles.info.d/*.info) and the user-installed things (~/.eclipse/<versioned directory>/bundles.info or something like that). In a shared scenario, we likely want the system-installed bits to "win". Another consideration here is the validation of the system-installed bundles.info snippets. During the RPM/dpkg creation, we can validate that all dependencies are present since they'll be around for the build. But runtime conflicts can also arise. I don't see a way around this other than mirroring the p2 metadata into the RPM/dpkg system. In Fedora we're already experimenting with these so-called "virtual Provides". Having "virtual Requires" to make the RPM/dpkg systems reject conflicting installations before p2 even has a chance to fall over is a good thing.
(In reply to comment #6) > /usr/lib/eclipse/bundles.info.d/*.info) and the user-installed things > (~/.eclipse/<versioned directory>/bundles.info or something like that). In a > shared scenario, we likely want the system-installed bits to "win". I think that only the platform bundles.info should always win and the rest should be merged as there are times when user installed bundle is newer and perfectly capable of satisfying even system bundles requirements but they are ignored resulting in user not really being able install things in his home directory. I know this opens a number of corner cases but this is one more area to be considered.
The primary goal I see is having the Eclipse UI *always* show up. Alex's suggestion of ensuring the Platform's bundles.info snippet always "wins" in cases of ambiguity is a good one towards this goal.
Unfortunately we did not get to this during the Juno timeframe, and I'm not sure that we'll have the resources to tackle this next year. I'm going to mark this as HelpWanted.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
