Hi,
I've just tested the update from Mars.2 to a local build of the EPP packages with the structural change. The update finished without error, but all features, that are declared as "root" in the new version, were simply uninstalled.
IMHO, this is pretty bad. Users who used to update their EPP installation in the past, now will find this workflow broken.
As a solution I suggest that we introduce new product IDs for the EPP packages which apply the structural change. This way we will prevent the broken update.
In addition we may continue maintaining the existing product IDs with the existing structure (at least for 1-2 releases), so all users, who used to update their EPP installations, can continue doing it.
Greetings,
Kaloyan
From: epp-dev-bounces@xxxxxxxxxxx <epp-dev-bounces@xxxxxxxxxxx> on behalf of Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx>
Sent: Tuesday, February 23, 2016 10:29 PM
To: Eclipse Packaging Project
Subject: Re: [epp-dev] Important structural change in Eclipse Neon
Hi Markus,
Thank you for the explanation! I'm OK with the upgrade not working from Mars -> Neon. As long as it works for Neon -> Neon+1 (unless the user installs incompatible stuff), I think the trade-off is reasonable.
Marc-Andre
From: epp-dev-bounces@xxxxxxxxxxx [epp-dev-bounces@xxxxxxxxxxx] on behalf of Markus Knauer [mknauer@xxxxxxxxxxxxxxxxx]
Sent: Monday, 22 February 2016 2:27 PM
To: Eclipse Packaging Project
Subject: Re: [epp-dev] Important structural change in Eclipse Neon
Hi Marc-Andre,
no, an upgrade from the old structure to the new structure is unfortunately not supported. Maybe someone comes up with a good idea/solution but I have my doubts.
Under the hood it uses a feature in Tycho that allows to define features as "root" features in a product definition. These root features behave like other features that have been installed into a package by the user; because of this it is possible to update
and/or remove them independently, but they are *really* independent. This brings the advantage that parts of a package can be updated much easier and independent from the package definition as requested by so many, but I admit that it has its consequences,
too, i.e. the package maintainer is only responsible for the initial package layout.
While this may sound scary to some of us (I used to be in this group in the past!), I'd like to compare it now with a Linux installation, e.g. a Ubuntu or a Fedora Linux. They all allow you to install a basic system that includes most of the tools required
by an average user. But this user has always the freedom to deinstall/remove certain parts, install other software, update parts or all of it.
Now a package maintainer has always the freedom to remove the installMode="root" in the product definition; this has the consequence that this feature cannot be removed easily by the user, but then an update of the EPP package metadata is required in order
to trigger an automated update in the field.
Example: The CDT project releases an important update. With the old package structure, or without installMode="root", a rebuild of the EPP package and its metadata is required. With the new structure the CDT project can trigger an update independent of EPP.
Sorry for the longer mail... I hope it helps to understand the situation better.
Thanks,
Markus
|