Re: [orbit-dev] different signatures, but same content orbit bundles?

[Roland Grunberg <rgrunber@xxxxxxxxxx>]

On Mon, 2020-10-19 at 13:18 -0400, Jonah Graham wrote:
> Thanks Roland for the extra background. That covers some of the
> cases. However I am seeing lots of cases of Orbit having a validly
> signed bundle, but SimRel has the older version in it because one of
> the projects with the dependency are using old (sometimes very old)
> orbits in their target platform. At the moment the policy is that
> Orbit does not contribute to SimRel directly, but each project does
> instead. Is there some way we can make sure that the bundles with the
> same fully qualified version in simrel are from the latest orbit
> build? 

This aspect has always been reliant on projects keeping up to date as
even projects using different version qualifier of some versioned
library from Orbit has caused issues before (due to range
requirements). In the case of the current release (or when 2020-09 was
under development), the latest orbit milestone/release is the way to
go.

For supporting older releases, it gets more complicated as it was never
intended to also re-sign bundles from already released repositories.


> Is this just an extra validation step we have to add, or is there
> something deeper going on here that I am unaware of.

This seems like the kind of thing that
http://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2020-09/index.html
could report. There's also the CBI Repo report. Does that get run on
simrel ? That could also detect things like duplicate versions if I
remember correctly.

-- 
Roland Grunberg