I've noticed that too ... now that we have three releases at one URL! ... bummer. And ... I seem to recall you have suggested this same improvement before, Thomas :) ... but please don't stop trying to improve things!
One counter view is that many people also want the characteristic that "once a URL works for something, it should always work" (i.e. repositories URLs are persistent, and "forever") ... for example, perhaps another product or project or build might really needs SR0 content, and they have printed books or tutorials on "how to install their product" or doing maintenance on their SR0 based product and it would stop working if SR0 content moved to a ...releases/indigo-with-legacy URL. (And, keep in mind, for what ever reason, they might really did need some very specific SR0 content constraint, and something would break for them if users started with SR2). Plus, I suspect many people would think that p2 should be in charge of p2 optimization, not the repository authors or creators (my personal view is that it could be a balance ... just stating a counter argument). For example, I have heard rumors that p2 does not currently take advantage of the "timestamps" that are part of every p2 repository metadata. Perhaps something like that could be used (by client-side p2) to better know "what to try first" and only fetch more, older stuff, if the most recent stuff doesn't satisfy constraints? Another possible approach ... but kind of a stretch ... might be some optimization from the opposite direction. We currently have our .../releases/indigo composite made up of sub-repositories with date-time stamp directory name. I have always maintained these should not be "published" and should not be considered "permeant" ... they might move to archives some day, there could times that even once "published" that "final date-time sub-repo" has to change to correct an IP issue, or, perhaps be "added to" to provide security patches, or something similar. But ... after all those qualifiers ... perhaps we could provide sub-repositories named such as SR0, SR1, SR2 that would be "published" and considered permanent, so those that really wanted only the very specific content could "manually" add those more specific software sites to their lists? This would mean, though, that each of those SRx repositories itself would need to be a composite, pointing to dated repositories (that could move to archives, or be changed "last minute" ... and, the problem with that, is that having "too many indirect children" is already a problem for some users (in a different way than what you are describing, having to do with frequency of HTPP "round trip" requests). Lastly, (in the least-likely-to-happen-anytime-soon category) ... if we could get people to make sure their version/qualifiers only changed when it was really required (i.e. their content substantially changed) we might do a better job of "pruning" the release repositories and minimizing quantity of changes. But this would take more work and effort from each project (both to produce the right stuff, and to test the final result), and more of a effort from the "common repo release engineer" (currently, me :) to maintain and quality-check the common (central) release repository. I don't mean to dampen discussions of improvements ... I'm sure improvements are possible and would love to see some and I would be willing to help (well, a little, if effort is small :) ... but, thought I'd mention these counter arguments to simply "moving old stuff to a different URL". I think that'd cause more problems than it would solve. My intuition is that any substantial improvements will take some substantial effort. Not to mention, I could be misunderstanding your suggestion, so do please keep the discussion going in any case, or, open a cross-project bug, if you think there is a problem that could be improved. Thanks, From: Thomas Hallgren <[email protected]> To: P2 developer discussions <[email protected]>, Date: 02/26/2012 08:23 AM Subject: [p2-dev] A typical use-case Sent by: [email protected] 1. I'm downloading and installing Eclipse Classic 3.7.2. 2. I'm installing something from Indigo. At step 2, I'm forced to wait while all children of the Indigo release are downloaded. Why? I'm only interested in SR2. The previous releases will just a) take a long time to download, and 2) consume a lot of memory when perused. I know there are cases where someone would like to revert to a previous install etc. and that all previous releases therefore must be available, but what I can't understand is why this must control the default behavior for the 99% of the users that never needs that. Why not let releases/indigo appoint the last release and have something like releases/indigo-with-legacy appoint the composite? Thoughts ? - thomas _______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev _______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
