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

[Niels Thykier <niels@xxxxxxxxxxx>]

On 2011-10-03 15:51, sami wagiaalla wrote:
> On 10/02/2011 10:30 PM, Pascal Rapicault wrote:
>> Sami, Niels, did you had a chance to capture your requirements wrt
>> Linux installs?
>> I did not see the description of what was below on
>> http://wiki.eclipse.org/Equinox/p2/Shared_Install
>>
> 
> I will do that right now while I am waiting for this eclipse build :)
> 
> 

Hey,

I will have a second look at the wiki and add some things I would like
to see included.  :)

>> [...]
>> Another thing to think about is uninstallation. Can it be assumed that
>> the interdependencies of sets of plugins laid down by the package
>> managers are captured in the metadata of the package. For example GMF
>> depends on EMF and depends on GEF. If there is a package for each of
>> these things, would the GMF package have deps on the EMF and GEF one?
>>
> 
> Yes, so the system will not remove a package without a warning about and
> removing packages which depend on it.  I assume this is the same for
> Debian.
> 
>   Sami
> 


Hmm... The dependency metadata is captured (modulo human mistakes in
said metadata etc.), but I doubt there is a "1:1" mapping between all
package manager's package/plugin states and events.

As I understand OSGi and eclipse, it is possible to have two plugins
with different version installed at the same time.  Generally this is
not possible with Debian's package managers (not sure about rpm, but I
doubt it can do that either)[1].
  I do not know if the eclipse manager uses this to fully install the
new version and then afterwards clean up the old one, but if it does
there is a potential issue here (depending on how it is done).

The (successful) upgrade process in Debian consists of ~6 steps:
 1 old version of the package gets a "pre-upgrade event"
 2 new version of the package gets a "pre-upgrade event"
 3 new version is unpacked
   - overlapping files are replaced
   - files only in the old version are left on the system
 4 old version of the package gets a "post-upgrade event"
 5 old files are removed
 6 new version of the package gets a "post-upgrade event"

If you want the "full story", there is a wiki page on the package event
scripts (a.k.a. "Maintainer Scripts").  I am not sure it covers all
states a package can be in, but it does cover most of the events we can
use in Debian packages[2].
  I am not sure about rpm packages, but I assume there is a similar
story (possibly less complex in terms of events).  Basically there will
be a time where part of the old plugins may remain and the new one is
fully installed.

If the basic flow for we are trying to do is something like:
 A eclipse package manager marks for upgrade
   - disables plugin and reverse dependencies etc.
   - steps 1 and 2 from the above
 B distro package managers unpacks the new version
   - steps 3,4 and 5 from the above
 C eclipse package manager updates metadata and re-able plugins
   - step 6 above from the above

then the above should not be an issue.  Of course I blantly assume that
a user is not running an eclipse instance during the upgrade in the
above.  :)

Secondly, there are cases where the plugin may be unpacked even if its
dependencies are not present[3].  Assuming the eclipse side will not
"magically" enable plugins in the shared install in these cases, there
will not be an issue.


How long is the "upgrade" part taking for the eclipse package manager?
I am mostly curious because if it takes a couple of seconds for each
plugin it acts on, it may be useful (at least for Debian) to enqueue
them and then process a batch of them later.

~Niels

[1] Work-arounds such as "renaming" the package (i.e. pkg and pkg2)
generally works as long as there are no overlapping files.

[2] http://wiki.debian.org/MaintainerScripts

I believe the full story is available in (parts of) the Debian Policy
Manual ch 6.

http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

Particularly: 6.5 to 6.8

[3] Cases of this include: A depends on B

  - Duing installation/upgrades, A may be unpacked before B, but B must
    be "configured" before A is "configured" (i.e. "upgrade complete
    event").


For the interested, the Debian Policy Manual (ch 7.2) covers when a
package can expect its dependencies to be present.  Particular the
reason for this case is hinted in the footnote #51.

http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps