[platform-update-dev] Update and RPM

[Tom Tromey <tromey@xxxxxxxxxx>]

I spent part of today reading the various update manager documents on
dev.eclipse.org.  I have some comments and questions.  I thought I'd
start with this one:

    http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update-home/doc/eclipse-installer.html

In particular I've been reading documentation with an eye toward
building Eclipse RPM(s).  We've got a hacked up RPM internally, where
we just packaged Eclipse 2.0 with the Gtk+ launcher and a Gnome
.desktop file; I can launch Eclipse via the nice icon on my panel.
This RPM isn't really suitable for actual use, and we need more info
about the update manager before we can make the first "real" RPM.


Anyway, first I'd like to address the two points near the top of the
document:

    * Product and extension interoperability. By behaving in standard
       ways, an installer for one Eclipse-based product or extension
       automatically works with products and extensions laid down by
       other installers. Otherwise the idiosyncrasies of one product's
       installer would require matching quirks in all extension
       installers that expected to work with that product.

I think we have conflicting worldviews here.  Here, we'll be
delivering a prebuilt Eclipse to the user using RPM (maybe installed
when the rest of the OS is installed, maybe installed via RHN or
something else).  We're not interested in supporting other installers.
In fact, that doesn't really make a lot of sense for what we do.  I
don't even know what other installers there would be.  Are there any?
Is this a Windows-specific requirement?


    * Uniformity of install time user interaction. All installers for
      Eclipse-based products and extension should interact with the
      user in the same manner. There is nothing to having gratuitous
      variety in this matter.

This doesn't really fit our model, either.  When you're using Red Hat
Linux, RPM is the standard.  If Eclipse requires something different,
then it is Eclipse being gratuitous.

So, for instance, I see this in the document:

    At install time, the installer should behave in the standard manner
    (further details follow the list of steps):

       1. warn user to exit all programs
       2. introduce the product to be installed
       3. if appropriate, ask the user for the name of the registered
       owner and for the license key 
       4. display the product's licensing agreement and ask the user to accept
       5. recommend a location on the disk to install the product (but
       allow user to override this default)
       6. check that a product or extension is not already stored at the
       specified location
       7. ask user to confirm all details of the install

We can't really do these things (especially not #1 :-).  Instead, we
want to build an RPM that works like all the other hundreds of RPMs
out there: you run `rpm -i eclipse.rpm' and you're done.

I don't know exactly how to suggest that this document be modified.
To my eye a lot of it is Windows-centric and just doesn't apply on Red
Hat Linux (or, indeed, on most distributions).


So where do we go from here?  We'd like our Eclipse install to
consider RPM as the standard way to install a new feature, with the
update manager being used either for private installs ("in the context
of a single workspace") or to manage un-RPMized plugins in /usr/local.

The "Eclipse Platform Update Packaging Conventions" document basically
rules out vendor packaging schemes on this basis:

    However, when using native platform installers, performing native
    uninstall creates problems because plug-ins would be removed without
    regard to any sharing relationships.

I don't fully understand this.  How is this different from the user
using "rm" to destroy their Eclipse installation?  Why protect against
it differently?  (From our point of view, most Eclipse plugins will be
RPMized themselves.  In this scenario, the dependencies will all be
correct anyway.)


One idea I have is to write a tool to take an Eclipse package and turn
it into an RPM.  I don't know enough yet to say whether this is really
possible (or desirable, for that matter).

Reading about the framework in 2.0 it sounds like maybe we could write
a new IFeature/ISite/IInstallHandler to let us handle things the way
we'd prefer.  Is that correct?

Maybe another choice would be to simply write a new document
describing how to package plugins for use with the Eclipse RPMs we'll
be building.  Then we could just disable the update manager.  That's
an extreme solution, though.

Tom