[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Update and RPM
|
OK Notes sucks for these kinds of conversations. That being said am using
<pm> again. sigh.
Thanks,
-----------------------------------
Peter Manahan
WebSphere Tools
Build/Install and
Product Architecture
------------------------------------
manahan@xxxxxxxxxx
Tom Tromey
<tromey@xxxxxxxxxx> To: platform-update-dev@xxxxxxxxxxx
Sent by: cc:
platform-update-dev-admin@ Subject: Re: [platform-update-dev] Update and RPM
eclipse.org
07/11/2002 02:29 PM
Please respond to
platform-update-dev
>>>>> "PM" == Peter Manahan <manahan@xxxxxxxxxx> writes:
PM> I have been looking at this stuff for some months so I added some
PM> comments. hope it helps
Thanks.
PM> The tone of your note seems to be assuming that you will be
PM> providing the RPM's all eclipse users will be using. This isn't
PM> the case. Each "product" will still have to write thier own rpm.
PM> However a default one for eclipse would be nice.
<pm>
According to the product and extension doc. Each "product" which is
basically a platform binary + associated plugins/features. So in your
case shipping the eclipse + CDT qualifies as a product according to those
docs :-)
</pm>
When you say "product", do you mean that if some company decides to
re-brand Eclipse and ship it, then they will need their own RPM? That
makes sense.
Right now I'm only concerned about the Eclipse we want to ship. What
we'd like to do is package the base Eclipse (i.e., the stuff in the
recent 2.0 release) and the CDT. Our requirements are basically that
it work like any other RPM package.
<pm>
It will work like any other RPM package.We ship WSAD that way and
for the WSAD based on eclipse we've packaged it differently than
the eclipse based on 1.0.
For eclipse itself (well it is wswb for us but it is basically the same
thing)
we have. Although the gtkversion should be able to sit along side the motif
version
on a machine (they need to rename the 2 launchers to something like
eclipse.motif and
eclipse.gtk though otherwise they collide). They should also ship the motif
libs as real rpm's
even though it may conflict with LessTiff (motif afterall is the one
lesstiff is trying to be
compatible with. (The rpm's exist for motif but am not sure of how the
licensing works.
Since they already ship the motif runtime shipping the motif runtime as an
rpm shouldn't matter).
So IMO this is what a real RPM of eclipse should look like (it won't of
course as each product will
do their own thing as you will be doing and WSAD will be doing etc. This is
what eclipse.org
should be shipping if they shipped an RPM. Loosely based on how they
distribute the downloads now.
Hopefully it will help drive out some issues which we've missed.
Assume /opt/eclipse as the base installdir.
1) eclipse-platform-dirs (this is a hack maybe you know of a better way.
What this installs
are the /opt/eclipse/features and /opt/eclipse/plugins directories. These
are the two directories the update
manager mainly updates. The reason for it being separate is so when it
uninstalls eclipse that this pkg erases the contents of the two directories
before removing them. All the pkg's
2) eclipse-platform - platform neutral platform binary
3) eclipse-platform-motif - the motif specfic piece includes eclipse.motif
launcher, SWT etc.
- this one should be the RPM that creates the "links" directory. The
gtk one that matches this
should do the same.
- as a post install step need to run "eclipse -initialize" which
basically sets up the initial config
for eclipse. (I think each "eclipse rpm" should run this as it sets
the main config. )
4) eclipse-platform-motif-WM - the window manager specfic shared objects.
Eclipse doesn't actually require
the gnome and kde desktops to be installed but RPM tries to add them as
dependencies because of these 2 .so's
so they are split out into a an rpm that doesn't do any dependency
checking. IMO they should be fragments on
their own the same as the gtk and motif peices of SWT. Find it annoying
cause I use windowmaker and don't have
gnome desktop or kde installed. Is there a better way to do this??
5) eclipse-platform-gtk - gtk specific pieces of the platform same as
motif
6) eclipse-platform-gtk-WM - same as the motif one.
7) eclipse-jdt - the jdt
8) eclipse-pde - the pde
9)eclipse-platform-source,
eclipse-platform-motif-source,
eclipse-platform-gtk-source,
eclipse-jdt-source,
eclipse-pde-source -- either in one rpm or multiple. Depends on if
you care about binaries matching the source. If you do you should have 1
source for each binary rpm.
10) The ones i missed :)
The above is probably overkill in general and is written if I were to do it
for a product.
You could take it even further and have one RPM per eclipse "feature" then
it would closer to
the way update manager worked.
</pm>
[ ... ]
PM> Its a windows "example". The standard manner for windows is
PM> different than the standard manner for Linux.
That explains a lot. The online document doesn't mention that those
are examples, let alone that they are windows-specific. I read them
as being general requirements.
PM> RPM's dependency checking isn't good enough (in fact no install
PM> program's dependency checking is good enough).
That's unfortunate. What do you suggest we do? I mean, given that we
have to use RPM.
<pm>
Use RPM for the initial install. The users can still download fixes etc and
if they
are root then they get laid down into the plugins and features dirs of the
core
eclipse install (yah it isn't nice that is why that extra rpm i describe
above is for. I hate uninstall errors.)
. If they aren't root they can select an alternate location to install to
but that is per workspace.
<pm>
Tom> One idea I have is to write a tool to take an Eclipse package and
Tom> turn it into an RPM. I don't know enough yet to say whether this
Tom> is really possible (or desirable, for that matter).
PM> Its possible to do this and it is desirable in to have one. As you
PM> mention below you need create a new feature type.
I'm confused; I don't know how to reconcile this statement with the
one above that says that RPM's dependency checking isn't good enough.
<pm>
Sorry, My head had context which I didn't write down :-). It is
desirable for the cases
where eclipse's dependency checking isn't enough :-). Eclipse understands
only the plugins/features
which it controls. What it doesn't understand are platform/product
dependency's outside of
eclipse. For example say I write a plugin that interfaces with say MySQL.
Eclipse has no way of
determining if MySQL exists on the system but RPM can be used for this. So
if an eclipse feature is actually packaged as an RPM then you get the
benefits of the plugins dependency checking of eclipse for the plugins and
the RPM dependency checking for system dependencies like MySQL.
</pm>
Tom
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
