Let's go through the scenario from a user with a shared install point of view:
A Windows 7 user downloaded an EPP package months ago, unzipped it into the program directory as a regular user (I was told that this is possible). After this initial unzip this directory and its content is read-only for this regular user, only an administrator is able to write and change the content from this point on. (Again, maybe I am wrong but up to this point I do not have the environment to test it.)
The user starts the new Eclipse and tries to install things from the Helios release. Since it is in read-only mode, the Helios repository isn't visible in the UI. Hmm, okay, not ideal but that's how it is. He then adds a new p2 repository to his configuration and installs something on top of his read-only installation. The install operation seems to finish successfully, but after the required restart of Eclipse the new software is not there. Very bad. That's because of the configuration problem in the packages and it is only visible if the package is read-only. If he would decide to do the update as administrator (i.e. with the Eclipse install being writeable / not in shared-install mode), then the additional missing bundles would be pulled from the Helios repository, bundles.info and the available bundles in the plugins directory are in sync again and everything works hopefully.
Now switching from the install additional software to the *update* use case. Again, I start with a read-only RCP package from the Helios release in June. As a regular user there is now way of updating it, but if you are doing it as an administrator it works and the additional slf4j bundles are on your disk after the update (even if they are *not* included in an EPP feature dependency). But again you have to educate the users that they need to be a Windows admin in order to do that.
That's all based on my own experience, tests, and knowledge so far. Maybe the p2 team can jump in and confirm what I wrote above. The point is that there is no need to include the slf4j bundles (or other optional bundles) in the SR1 packages because the new packages work without those bundles and they are generated with the correct configuration data. In the update scenario it looks to me that it doesn't make any difference whether the bundles are listed as required or not.
The EPP transition feature that I am providing as a test in the p2 repository below can be installed explicitly and then uninstalled and will remove the additional slf4j bundles. That would be a clean-up procedure if someone complains about too many log entries in the updated package.
Markus,
I read your (well written) comment on the bug, and I understand the
path of reasoning that it follows. However, I want to point out
that, even though it's a small percentage, the shared-install users
WILL be annoyed at this and I suspect at least few of them will be
quite vocal about it. We must learn a lesson from the Java 1.6u21
debacle, that lesson being the PR hit we can take, even when there
are work-arounds and help available, can be sever.
Believe me, I'm a purist at heart, someone who usually values
"cleanliness" above all else; the idea of including some bundles for
no other purpose than to avoid a broken previous build is not
pleasant. But I'm also a community advocate, and I don't want to
have to answer yet another question about "why doesn't Eclipse
work?" to users. The reputation hit shouldn't be discounted.
I don't understand the point about unknown side effects; don't we
have time to thoroughly test the update scenarios so that we feel
confident there are no unintended side effects?
It seems we have two paths, one that is the "clean" approach, but
leaves some users in the lurch and hopes that they will know where
to go for help and have the/time patience to get it. The other
option is less clean but is transparent to everyone. It's a
difficult decision to choose between them, but I would opt for the
one that is transparent so long as there's a way out of including
the extra bundles forever (which, IIUC, there is since the latest p2
component won't need them).
Eric
On 9/13/10 10:30 AM, Markus Knauer wrote:
In
order to keep you updated about the progress with the Helios SR1
RC3 packages:
In comment #21 of bug 322929 (see [1]) I tried to sketch my
proposed solution for the configuration problem in shared installs
of the EPP packages. My own focus has changed and my top priority
is now to deliver SR1 packages that do not contain the problem any
more (of course), but also not to include bundles in SR1 just
because there were problems in the June release. My feeling is
that this is too risky and that we should not change the
configuration of the packages between the release and a service
release. On the other hand that decision means that we need to
educate some users that are using EPP packages in a shared install
and are trying to update to SR1. More information and comments
should be done on the bug.
The current status is that I now have a new metadata repository
available based on this proposal. It can be found here [2] and is
being used for the packages that a still building [3]. I will ask
the package maintainers later today to test and sign off this
build.
