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

[Pascal Rapicault <pascal@xxxxxxxxxxxx>]

On 2011-09-24, at 8:00 AM, Niels Thykier wrote:

> 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).
	Running the director without the exe is not a problem. We just need to figure out the location of the org.eclipse.equinox.launcher jars. However note that the .eclipse folder is not created by the exe but by the launcher previously mentioned. If we can't get rid of it, it should also be possible to have that be stored in a tmp folder by specifying the adequate parameter.
	As for running without a workspace, given that p2 never uses the workspace, it should suffice to specify -data @none on the command line for the workspace to not be created.

HTH

>  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.
> 
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev