[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Update and RPM
|
I have been looking at this stuff for some months so I added some
comments. hope it helps . Used <pm>
The tone of your note seems to be assuming that you will be providing the
RPM's all eclipse users
will be using. This isn't the case. Each "product" will still have to
write thier own rpm.
However a default one for eclipse would be nice.
Thanks,
-----------------------------------
Peter Manahan
WebSphere Tools
Build/Install and
Product Architecture
------------------------------------
manahan@xxxxxxxxxx
|---------+------------------------------------->
| | Tom Tromey |
| | <tromey@xxxxxxxxxx> |
| | Sent by: |
| | platform-update-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 07/09/2002 06:12 PM |
| | Please respond to |
| | platform-update-dev |
| | |
|---------+------------------------------------->
>-------------------------------------------------------------------------------------------------------------------|
| |
| To: platform-update-dev <platform-update-dev@xxxxxxxxxxx> |
| cc: |
| Subject: [platform-update-dev] Update and RPM |
| |
| |
>-------------------------------------------------------------------------------------------------------------------|
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.
<pm>
You seem to be making several assumptions. You need to look at the
documents
with an expanded worldview. :-) I.E. RedHat isn't the only Linux
and RPM isn't the only installer and there are more OS's. If you are not
interested in doing any installers at all that would be fine I'm sure. (I'm
not sure I
understand your point? Have you been asked to provide an RPM for eclipse?
No one is asking you
to support other installers.)
Anyway the RPM you are writing won't be the one products will use. Each
needs
to ship their own eclipse. For example WSAD will ship its own version of
the eclipse platform
on RedHat and Suse. It will be using RPM (basically because I believe using
the "platform" installer
is "the right thing to do". But the product installs will be totally
orthogonal to the one you
may be creating.
</pm>
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?
<pm>
Not it would be for all platforms
</pm>
* 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.
<pm>
You are missing the context. What it means is that each product should use
the
appropriate installer for the platform it is running on. For RedHat it
would probably
be RPM, Debian has their own, AIX has installp etc.
</pm>
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.
<pm>
Its a windows "example". The standard manner for windows is different than
the standard
manner for Linux.
</pm>
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).
<pm>
The examples are windows. There are key parts which generalize to multiple
platforms,
Its probably easier to see if you have more exposure to multiple install
programs.
It needs to be worded more generally I guess.
</pm>
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?
<pm>
Don't forget corporate products with big support contracts will be using
eclipse.
Attempting to prevent users from shooting themselves in the foot is job 1.
There is a very complex set of behavior that occurs with plugins and
versions
when eclipse loads. This is managed by eclipse and a native uninstall would
have to
implement eclipse's loading mechanism to verify that uninstalling something
wouldn't break something else. RPM's dependency checking isn't good enough
(in fact no install program's dependency checking is good enough).
</pm>
(From our point of view, most Eclipse plugins will be
RPMized themselves. In this scenario, the dependencies will all be
correct anyway.)
<pm>
The smallest unit of install should be a feature not a plugin. And the
dependencies will not
necessarily be correct in the scenario you mention. That would be a very
bad assumption to make.
There is no way you can make it be correct without using the eclipse
platform loader to do
the checking.
If you use RPM to update a plugin you have to leave the original plugin
that is
already on the system. Once a feature is laid down it should
not ever be removed until the complete eclipse is removed.
So for example if i have plugin com.xyz version 2.0.0 and I upgrade
it to com.xyz version 2.1.0 then I have 2 plugins installed
version 2.0.0 and version 2.1.0 the previous version should not be
removed.
</pm>
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).
<pm>
Its possible to do this and it is desirable in to have one. As
you mention below you need create a new feature type.
</pm>
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?
<pm>
Yes that is correct. But you need to understand how the update
manager works and where features and plugins get laid down.
For example the RPM's would all have to be relocatable as
eclipse defines the <installroot> for a particular feature.
</pm>
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.
<pm>
Eclipse is multi platform. I understand your point of view but eclipse runs
on
more OS's than RedHat Linux. If I create my cool new eclipse feature I am
going to ship it as defined by eclipse default first. Then users on
windows,linux,aix,hp, sun
etc will all be able to install and use it. The only time I would consider
shipping a feature as an RPM is if I needed .
All updates would use the update manager.
If you go the route of removing the update manager most people woule
probably
go download thier own copy of eclipse. Because update manager is how
eclipse
updates itself and provides an easy mechanism to add new function.
And you are removing that functionality.
I for one wouldn't use it as it had been crippled.
</pm>
Tom
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
