Bugzilla – Full Text Bug Listing
| Summary: | Howto transparently move p2 repos to archive.eclipse.org? | ||
|---|---|---|---|
| Product: | Community | Reporter: | Stephan Herrmann <stephan.herrmann> |
| Component: | Cross-Project | Assignee: | Cross-Project issues <cross-project.inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, mknauer, pwebster, sbouchet, steffen.pingel, webmaster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Stephan Herrmann
(In reply to comment #0) > I've experimented with this for a while including using the p2 tracing > options but never saw any access to archive.eclipse.org. To be more explicit about this failure: Since the metadata were all still on download.eclipse.org I could work through all stages of the install new software wizard, only when clicking finish it failed saying it found no repository containing each of my artifacts. That's when the switch from download to archive should have happened, but didn't. Adding webmaster to CC... maybe they can add some background information about the download/archive server story. I'm not sure if very many people have moved any p2 repositories to 'archive' ... simply because there has not been that many releases that used p2 repositories. Two prior to Indigo? So, it's just now that we are starting to get "old stuff" in p2 repositories. (So, all the more compliments to Stephan for pushing forward on this). I know we in webtools have archived some of the early parts of the Helios release, and we used the composite approach Stephan mentions. So, just to give an example, our main site for a release is a composite repo, such as at http://download.eclipse.org/webtools/repository/helios/ our artifacts composite looks like the following ... with some references pointing to "archive" and some still pointing to "download". <children size='5'> <child location='http://download.eclipse.org/webtools/downloads/drops/R3.2.3/R-3.2.3-20110217214612/repository/'/> <child location='http://archive.eclipse.org/webtools/downloads/drops/R3.2.2/R-3.2.2-20100915173744/repository/'/> <child location='http://archive.eclipse.org/webtools/downloads/drops/R3.2.1/R-3.2.1-20100730021206/repositoryb/'/> <child location='http://archive.eclipse.org/webtools/downloads/drops/R3.2.0/R-3.2.0-20100615235519/repositoryb/'/> <child location='http://download.eclipse.org/webtools/downloads/drops/R3.2.4/R-3.2.4-20110511033327/repository/'/> </children> We moved the directories from download to archive with a simple copy command. No other changes, that I recall. And all remains transparent to p2 end/user clients. Please let us know if there are flaws in this approach. So, true, we always use composites, and sounds like the part of the complication Stephan was having was when the main site was not a composite, but instead a simple site? But, seems conceptually the basic procedure should still work. Conceptually, leaving 'archive' out of it, you should be able to "convert" that main site to an composite first, right? Such as move what was there to a subdirectory, say "ot07" and then use that "ot07" directory in your composite file. And, from there, move "ot07" to 'archive' (and update composite references, of course). I think that approach would be preferable to editing "mappings" element. I know nothing about the design or purpose of "mappings" element, but seems I've never seen anything hard coded in there. Always variables? And, I've heard and had some experience with the fact that its always better to use p2 APIs or ant tasks to work with repositories. For example, once hard coded like that, what if someone used p2.mirror task to try and make their own copy of that repository ... would it still work? Maybe. But, my point is, there's many uses of repositories, and not sure us non-experts really know the effects of hand-changing the metadata, so even if one use-case works, there might be other use cases that do not. I will, also, add that I think Stephan's ideas about leaving content meta data on 'download' and moving artifacts to 'archive' is a good one, and would require use of the p2.mirror tasks (if that's not obvious). But, I've never tried it. I've often thought that'd be an ideal case to have "artifacts" at a separate location than content metadata, since, after all, "artifacts" are the big meaty part that would save space by being on archives, and leave the content metadata where it was ... but, like I said, I've not tried it. It might take a type of "conversion" to change a simple site, to one more complex (that is, it's not just copying directories). But seems the p2.mirror task should be able to work. But, definitely not mirrorsURL. That doesn't really do anything much, doesn't "direct" p2 to do anything ... simply provides a hint that p2 might want to make use of. Even then, p2 has been designed so all mirrors can fail, but p2 still work ... just hints. One more small note on procedure ... I'm not clear on Stephan's exact steps and procedures, but using "tracing" to see things coming from "archive" URL might (depending on details) be expected to not work ... right away. Depending on how things were done, it might take a while (hours, days, or week?) for things to no longer exist on mirrors ... but, again, would depend on the exact procedure which I'm not clear on, but I have a vague memory of myself seeing and being confused about that, long ago. Hope these ramblings help. I'm looking forward to hearing how others solved this problem. I guess the howto question is pretty much resolved with the advice to always use a redirecting composite repo. |