Great. I certainly assumed that it would be a widespread problem.
Another thing that we should check for is random bundle versions. For example, the Galileo SR1 repo has three org.eclipse.osgi IUs, one from 3.5.0 and two from 3.5.1. As with Orbit bundles, people who are including hard dependencies on old/different versions of stuff from other projects should have to explain why. In this case I suspect that the OSGi bundle was rebuilt on 0827 and some other project built a feature that included org.eclipse.osgi but they had an old Equinox in their target/base.
Given that we have all the metadata in one spot it should be relatively easy to write a consistency checker.
Jeff
On 2009-10-09, at 8:56 AM, Pascal Rapicault wrote: Now that the SR1 craze has calmed down, I think it is important to try to get the SR0 bytes in place.
Not only Jeff is affected, but potentially everyone trying to revert form SR1 to SR0 will have problems which will result in yet another set of bugs in the p2 bucket.
<graycol.gif>John Arthorne---10/08/2009 10:37:41 PM---Pascal noticed this the day before the release, but it seemed risky to be playing with a new repository structure right before
<ecblank.gif>
From: | <ecblank.gif>
John Arthorne/Ottawa/IBM@IBMCA |
<ecblank.gif>
To: | <ecblank.gif>
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> |
<ecblank.gif>
Date: | <ecblank.gif>
10/08/2009 10:37 PM |
<ecblank.gif>
Subject: | <ecblank.gif>
Re: [cross-project-issues-dev] Galileo has left the repo |
Pascal noticed this the day before the release, but it seemed risky to be playing with a new repository structure right before the release, after performing all the testing with the existing structure. David pointed out that previous simultaneous releases did the same thing, and I think changes would be needed to the galileo builder/aggregator to make this happen. In any case I realize all the discussion about this happened offline, so I've opened a bug to carry on discussion about it:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=291848
Minimally I think we've agreed to shoot for this (immutable repository content) for Helios, but I'll leave David to comment on whether we can do something with the galileo repository. Note the eclipse top-level project repository has both SR0 and SR1 content, so the multiple org.eclipse.osgi bundles you are seeing are likely coming from there.
John
I'm not sure if I missed something but it seems that the Galileo repo
no longer contains Galileo! Rather, it just contains Galileo SR1. This
is fundamentally problematic as it makes it impossible to have a
stable reference to content. This in turn makes it very challenging to
a) create a reproducible builds
b) create durable toolchains
c) use PDE target platforms with the software site provisioning
facilities
Just one detailed example, the PDE target platform support for p2
repo. Target definition files maintain a list of features and
versions that are part of the target. Me and my team have a mess of
such targets and in fact, we are distributing a .target file as part
of the code for the Equinox book. I happened to go and test our setup
today only to find that the content was all gone and the target failed
to load because the features are missing from the repo. It looks like
some of the old bundles might be there (found three versions of the IU
for org.eclipse.osgi!) but that's no good unless you have the over-
arching structure.
I humbly propose that
a) we restore the Galileo content
b) in future release repos are monotonic (love that word). No
deletion is allowed
c) we put in place tests that in fact ensure that nothing is deleted
(in both the metadata and the artifact repos)
Jeff
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
