check for updates on local update sites

[gireeshpunathil]

I wanted to raise a bug report but then thought it is prudent to first ask here because of a potential paradox involved in the use case (if you already have valid updates downloaded locally it is funny to check for updates?): Is check for update designed to work with local update sites? I tried with a sample feature and found that the wizard does not pick it up any. I have verified that it works fine through the install new s/w route.

If someone can assert that it is valid scenario, I will debug further and come with more findings.

[mickaelistria]

Yes, Check for updates is supposed to work with any update site. Whether it's file:/ https:/ magnet:/ (there were some experiments about it) or whatever source shouldn't matter to Check for Updates.

[laeubi]

What do you mean with "does not pick it up", has the content of the site actually changed since last time you installed from that location? Nerveless I can imagine that there is somewhere a check in that P2 feature that skips for local sites.

[gireeshpunathil]

has the content of the site actually changed since last time you installed from that location?

there was't anything there previously. I am creating a local site by hand, and I validate its correctness by using it through install new s/w route. Will share more details soon. thanks!

[merks]

Note that p2/pde don't always do a great job unloading and reloading repositories such that they "see" changes at the target URI. There are often soft references to loaded repository content that are reused...

[laeubi]

I think it only works if you actually install something from there and it must have a higher version. But as said P2 also has some special handing for local sites that maybe apply here as well.

[gireeshpunathil]

ok, here are the steps that I followed:

• file -> new -> other -> plugin development -> feature patch
• in the wizard, give a name and select an existing feature (say org.eclipse.help) for the properties of feature being patched)
• finish
• file -> export -> as a deployable feature
• finish
• help -> check for updates. none found, as expected
• update the update site to point to the exported location and try again. none to update
• try the last step with install new s/w. it works.

Am I doing something wrong here?

[merks]

Maybe it's just a wrong assumption. I don't think that a patch is an update. I think a patch must be explicitly installed.

[laeubi]

Maybe it's just a wrong assumption. I don't think that a patch is an update. I think a patch must be explicitly installed.

I would think so as well... So the best is to first verify it with a http deployed site that then is made local.

[gireeshpunathil]

I don't think that a patch is an update

then what qualifies for an update? only features with major / minor version bumps?

So the best is to first verify it with a http deployed site that then is made local.

thanks, will try that.

[merks]

An update is a feature for which there is a newer version available, i.e., exactly the same existing ID with a version that's higher. I'm not so familiar with patches, but as I understand it, they are intended to modify/augment/change an existing feature. So I think AspectJ provides a patch to JDT's feature and you have to install it explicitly for that purpose....

[laeubi]

@merks that's why I think it could work to install that patch and then have an updated patch (with the same ID of course). But something not installed will trivially never trigger an update regardless of the type of site and/or change....

[merks]

Definitely. An update is any root install unit (IU) for which there is a higher version available, i.e., same ID with higher Version. Then p2 will create a new root request for that newer IU...

[gireeshpunathil]

some interim update: I was looking at the p2's update operation logic here
https://github.com/eclipse-equinox/p2/blob/1af3d0fcb08073e7c9fe07a914988d3e7b2da816/bundles/org.eclipse.equinox.p2.operations/src/org/eclipse/equinox/p2/operations/UpdateOperation.java#L165-L257

looks like it caters to patches as well. however, the iusToUpdate list does not contain the (base) feature that I am interested in! can it be that this list contain only top level features? (features that are installed as IUs, not the ones that got installed as part of other features)

the list (iusToUpdate):

org.eclipse.tips.feature.feature.group
org.eclipse.e4.core.tools.feature.feature.group
org.eclipse.sdk.ide
org.eclipse.egit.source.feature.group
org.eclipse.egit.feature.group
org.eclipse.e4.core.tools.feature.source.feature.group
org.eclipse.tips.feature.source.feature.group

my feature is org.eclipse.help

[merks]

Yes, there is the concept of root IUs e.g., org.eclipse.equinox.internal.p2.ui.sdk.scheduler.migration.MigrationSupport.getUserRoots(IProfile) and only those are considered for update checking.

[gireeshpunathil]

that explains! further debugging confirmed your theory: I am able to discover as well as install patches from local URIs through check for updates function - as long as those are patches of root IUs.

Install s/w function does not have this condition: it lists / installs patches of any features / plugins. Not sure if it is a bug or design. WDYT?

thanks @merks and @laeubi for the quick pointers! good learning for me today!

[merks]

It is definitely by design to only update root features, though sometimes folks really do want "deep updates" (which is what Oomph's p2 director task does via Help -> Perform Setup Tasks, when that's installed).

[gireeshpunathil]

nothing outstanding on this thread as of now, closing.