[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[p2-dev] Linux packages of RCP, Platform, JDT, PDE

Hi,

I'm working on RPMs of Eclipse 3.4 for Fedora.  I've got SDK packages
and they work fine.  I build from source, generate metadata, provision
using the director, and can run p2.user.ui just fine.  Thanks for all
the hard work!

In Fedora, we have tried to match the upstream offerings.  For example,
we ship packages (RPMs) called eclipse-{rcp,platform,jdt,pde} to match
the various released zips and features.  I have a plan for how to do
this in this futuristic p2 world in which we are living:

- build entire SDK
- generate metadata for SDK
- provision SDK using p2 director
- copy bundles.info to 3-sdk-bundles.info
- generate metadata for everything that makes up jdt
- provision jdt using p2 director
- copy bundles.info to 2-jdt-bundles.info
- generate metadata for everything that makes up platform
- provision platform using p2 director
- copy bundles.info to 1-jdt-bundles.info
- generate metadata for everything that makes up rcp
- provision rcp using p2 director
- copy bundles.info to 0-rcp-bundles.info

RPM has the concept of "pre/post" and "preun/postun" scripts that get
run when a package is installed/uninstalled.  The ordering of these on a
package upgrade makes things a little tricky:

new pre
<new files laid down>
new post
...
old preun
<old files removed>
old postun

I think putting something like the following into all of the sub-SDK
packages' post *and* postun scripts will work:

rm <main bundles.info>
biggest=$(ls -1 subBundles/ | tail -n 1)
ln -s $biggest <main bundles.info>

The main bundles.info will therefore be a symlink to the "biggest" part
of the SDK that is installed.  There will be no need to do any fragile
"we just removed jdt, move symlink to platform" which would rely on
ordering of installation/removal (possible, but I'm not very interested
in doing this).

I'd appreciate any feedback on this.

Thanks,

Andrew