[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cross-project-issues-dev] On the topic of funny and old things in logs and repos
|
In reply to Laurent's note, (see below but with different subject
line ... )
Short answer would be: Yes, there are problems, but nothing to "wreak some
havok".
Long answer: There's a few ways to explain what's going on, and to answer
your questions, and to say what steps to take next.
First, you'll notice those messages about "mirroring meta-data reference
...." are no longer in the juno aggregations, just indigo logs. This was
covered in bug 358415 [1].
In short, it was decided not to copy the "reference repos" that projects
have in their own repos, because there was too much junk in there, and
despite _years_ of pleading, no one cleaned them up.
But, it is true, still a problem with Indigo. And while less a problem in
Juno, it is it still somewhat a problem even there, since if someone does
"manually" add a new software repository to their list of sites, (or, if an
EPP package does) and if that software repo happens to have "old" reference
repos in it, then p2 will (still) copy them to the clients list of software
sites (typically disabled, initially). p2 does this partially to retain
functionality what was available with old update manager ... where one repo
site could have a "sister site" they wanted users to see. But, without
maintenance and careful thought this convenience just turns into junk.
So, that steps to take? It is hoped that when it matters to consumers;
users or adapters, they will open bugs against the specific projects to let
them know they are bothered by the junk reference repos in those project's
site. But this is similar to any other bug in another projects code ...
there's nothing overall we an do to dictate which bugs they fix and which
they don't. But the junk will no longer be in the common repo (beginning
with Juno).
The good news is some of the "junk" is left out or becomes irrelevant if
users use the common repo. That is the Indigo Papyrus install will still
work, and (in indigo repo) just add "junk" reference repos to the software
repository list.
I'm less sure what to say about the old Orbit repos. If they are reference
repos, then the above applies. If people are still using them to actively
get "old" Orbit content, then in most cases (but not all), when end users
do installs, they still get only one, the newest version of a bundle
installed by the way p2 works (and typically, only one would be used at
runtime, though, agree it could mean some people test with one version, but
end users are using another version). But, at best they are "wasting space"
in common repo. But, it is not much wasted. There are only a few cases of
obvious duplication. There's a report for that:
http://build.eclipse.org/indigo/simrel/reports/nonUniqueVersions.txt
Some cases in there make sense and are intentional for different parts of
code to intentionally use different versions and both versions can coexist
in same install and both run at same time (since non-singletons), such as
javax.wsdl
1.6.2.v201012040545
1.5.1.v201012040544
But, others cases are just crazy and obvious cases of people not using the
right Orbit repo or some how having their own, old copy in their own
repository.
javax.activation
1.1.0.v201005080500
1.1.0.v201105071233
1.1.0.v201108011116
Hope these (wordy) answers help explain a little. Feel free to open bugs
against projects where you see issue with their repositories.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=358415
From: Laurent Goubet <laurent.goubet@xxxxxxx>
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 02/17/2012 04:37 AM
Subject: Re: [cross-project-issues-dev] Fw: Indigo SR2 staging repo is
complete ... again
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
When I look at the aggregator build log [1], I can see some references
to "old" versions of the update sites? For example :
[exec] Mirroring meta-data from from
file:///home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.8/SR2_RC4/main
[exec] - mirroring artifacts
referencehttp://www.eclipse.org/modeling/mdt/?project=papyrus#papyrus
[exec] - mirroring meta-data
referencehttp://download.eclipse.org/tools/gef/updates/milestones/
[exec] - mirroring meta-data
referencehttp://download.eclipse.org/modeling/mdt/papyrus/updates/releases/
[exec] - mirroring artifacts
referencehttp://download.eclipse.org/tools/gef/updates/milestones/
[exec] - mirroring artifacts
referencehttp://download.eclipse.org/modeling/mdt/papyrus/updates/releases/
[exec] - mirroring meta-data
referencehttp://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.8
[exec] - mirroring artifacts
referencehttp://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.8
[exec] - mirroring meta-data
referencehttp://download.eclipse.org/modeling/emft/eef/updates/0.7.1/
[exec] - mirroring artifacts
referencehttp://download.eclipse.org/modeling/emft/eef/updates/0.7.1/
[exec] - mirroring meta-data
referencehttp://download.eclipse.org/modeling/gmf/updates/milestones/
[exec] - mirroring artifacts
referencehttp://download.eclipse.org/modeling/gmf/updates/milestones/
[exec] - mirroring meta-data
referencehttp://www.eclipse.org/modeling/mdt/?project=papyrus#papyrus
If I am reading that well, this means that somewhere on the update
site, someone is referencing a version of EEF (0.7.1) that is old, not
contributed to indigo... and not built for this release altogether. EEF
is itself contributed to the repository :
[exec] Mirroring artifacts from from
file:///home/data/httpd/download.eclipse.org/modeling/emft/eef/updates/releases/1.0
[exec] - mirroring artifact
osgi.bundle,org.eclipse.emf.eef.mapping.edit,1.0.2.v20120216-1513
...
I believe that this might wreak some havok when people will try and
install papyrus. I also saw references to three distinct orbit update
sites in there:
-
http://download.eclipse.org/tools/orbit/downloads/drops/R20100519200754/repository
-
http://download.eclipse.org/tools/orbit/downloads/drops/R20120119162704/repository
- http://download.eclipse.org/tools/orbit/downloads/drops/updateSite
Wouldn't that be a potential issue waiting to bite the users?
As a side note, adding the update site into an eclipse and letting p2 do
its job yielded an exception (full-featured with a nice, modal
popup-dialog) that told me "No repository found at
http://download.eclipse.org/gyrex/0.10/R-0.10-201106150229";. If I am
right, this update site is now located on "archive.eclipse.org"... The
issue is that it somehow ended up defined in my "available update sites"
... and made p2 fail.
This update site might have been there before I added the maintenance
one in my eclipse's p2... but that will also happen to consumers. This
raises the question : should we really archive the update sites?
Changing the url of an existing update site, an url that gets added
automagically to p2 when we browse other update sites or install other
softwares (I don't even know what gyrex is, it just "got there") will
make p2 throw an exception. Exception that is displayed in a modal,
error-red popup displaying a message that is irrelevant to most users. I
believe that 1) we should not change a published update site's url,
whatever the reason and 2) p2 should log the exception, not open a popup
dialog.
Laurent
[1]
https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/indigo.runAggregator/lastBuild/consoleFull
[attachment "laurent_goubet.vcf" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
