Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] weird MPC versions causing grief

Hey all,

thanks, Leif, for the reproducible steps. I did bang my head against this last week for a bit but couldn't reproduce the problem. Some comments below:

> I had a closer look at the issue. I found, that for the 2019-12 release the
> version of MPC that was promoted for Release and Simrel Composite was
> newer than the one in the epp-mpc.aggrcon file. That might have caused the
> problem to occur even more often. I double checked that this will be correct
> for the 2020-03 release.

We should make sure that in addition to the promoted MPC version we also keep the version around in the MPC release repos that ended up in the release train. I'll dig up that repo and promote it as well.

> session context was:(profile=epp.package.jee,
> phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=,
> action=).
> 
> No repository found containing: osgi.bundle,com.sun.jna,4.5.1.v20190425-
> 1842
> 
> No repository found containing:
> osgi.bundle,com.sun.jna.platform,4.5.1.v20190425-1842
> [snip]
>
> Being easy reproduceable, I doubt that this is some kind of caching problem
> here. As Ed mentioned, it does not look like a MPC problem either. 

The strange part here is:
1. The repos involved (SimRel 2019-03 and MPC 1.7.7) have both been around for a rather long time, so I doubt that anyone would have caching issues here anymore.
2. All the unresolveable artifacts come from the MPC 1.7.7 repo exclusively, i.e. they do exist there, but don't exist in the older simrel repo (at least not in that version).

To me this looks like P2 included the MPC 1.7.7 metadata repo in its planning stage, but then somehow ignored the MPC artifact repo completely during download. 

I've had a couple of similarly suspicious-looking update issues with unrelated installations in the past, but was never really able to reproduce them. Maybe this is the chance to get to the bottom of that.

> Of
> course, we could deactivate the update mechanism of MPC for RC2, which
> might reduce the number of problems, but does not solve the root problem
> and of course makes MPC updates harder for all our users that do not have
> this problem. Any opinions?

A few words about the MPC update mechanism:

First of all, while we're only talking about MPC updating itself here, that updater is not specifically for updating MPC. MPC is just eating its own dogfood here in the sense that it checks all installed Marketplace solutions that it knows about for updates, and if it finds any, it shows an update prompt. Depending on the updates found, this prompt takes the form of a general update prompt ("Some of your installed plug-ins have updates available."), or one specifically about MPC ("A new version of the Marketplace Client is available. ").

This update check differs a bit from what Check for Updates does in that it doesn't consult the repository list, but the Marketplace catalog. This means that for example a plug-in A might have previously had a version 1.2 published on the Marketplace with an update url of http://example.org/updates/releases/1.2, and now has updated its listing with the new 1.3 release and an update url of http://example.org/updates/releases/1.3. This would not be caught by Check for Updates, since the repo list would only contain the old unchanged site.

The general functionality of this update check has been around for a pretty long time now. What has changed a couple of releases ago (with Photon IIRC) is that a) we proactively trigger this update check (previously it only happened when you opened the "Installed Software" tab in MPC, or came across a listing in the search view which you already had installed) and b) we show that banner to make available updates more visible.

One thing that I think should be fixed regardless of the current grief is that in the process of checking for updates, MPC potentially adds new repos to the list and doesn't clean them up again (as so aptly expressed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=560062#c12). I'll open a new bug for this.

Best regards
Carsten

Back to the top