Re: [p2-dev] Sharing Your Shared Install Issues

[Niels Thykier <niels@xxxxxxxxxxx>]

On 2011-09-23 18:01, sami wagiaalla wrote:
> Hi Domenico, DJ, all
> 

Hi

Thanks for starting this initiative.  :)

>> [...] This bundle pool holds all of the
>> features/plugins already in installed format. So, when a user uses P2 to
>> install from here, really it just updates the bundles.info, platform.xml
>> and SDK profile to load from this bundle pool.
> 
> This kind of functionality would make work nicely with rpm. RPM really
> needs to do the adding and removing of the files being installed. With a
> solution like the above we can do something like this:
> 
> The platform rpm would install the platform plugins into:
>   /usr/lib/eclipse/{feature,plugins}
> 
> Then a plugin rpm like eclipse-jdt can install things (in a runnable
> state) into:
>   /usr/lib/eclipse/repos/jdt (or any other suitable location inside or
> outside the eclipse directory)
> 
> Then run the director to install things from this location (bundle
> pool?) into /usr/lib/eclipse/configuration/.../bundles.info et. al.
> without moving the artifacts of course.
> 

With my Debian maintainer hat on, I somewhat interested in making the
director runnable without using the eclipse executable.  That front-end
has an annoying habbit of writing to ~/.eclipse and the default
workspace.  This is inconvient (at least from my PoV).
  This is not strictly required, since we are already able to "control"
where it writes that.  Nevertheless, I would prefer not having to set up
a "fake" home and workspace to avoid eclipse writing stuff to /root/
during installation and upgrades.


> The other thing needed for rpm is to be able to verify that the
> provisioning will go through successfully before actually doing it. This
> is important because the rpm is doing this as root user. I believe
> -verifyOnly accomplishes this. If so, then this is just meant to
> emphasize its importance.
> 
> [...]
>
> Cheers,
>   Sami

This applies to Debian as well.  Though, I am curious - do you want to
run this during build or install.  Personally I assume it is the former
case, thus only direct dependencies of the build process and the plugin
being built will be present during the verification[1].
  I doubt it will be an issue, but I prefer we spell it out rather than
assuming the others think/assume the same as we do.  :)


I also added a suggestion on how to handle Bug 304132 on the wiki.  I
believe it would also solve Bug 351485 (actually I suspect 304132 and
351485 of being duplicates).


Finally I believe it would be good idea to improve the error handling in
this error.  One of the most frustrating parts (at least for me) has
been debugging why eclipse "silently" drops/refuses to load user plugins.
  I have not added this to the wiki yet, I was not sure if a bug was a
requirement or not.  :)

~Niels


[1] or rather, those are the only things we can rely on being present.