What you need to realize is that whether the repo is validated or not, the remediation will still happen when the user try to install something (or install a new version) that is incompatible with what is already installed. For example with this hypothetical scenario:
- Imagine the user has the platform and GMF installed with a tight dependency on the platform. When the user decides to install the new version of the platform, then the installed version of GMF is no longer suitable, so the remediation will kick in. This will happen whether the p2 repo the user is installing from is validated or not. This is simply rooted in the fact that the user only wants to install one particular component without any desire to understand the dependencies. The only case where the user would not see any remediation is the check for updates. This is because in Kepler we've improved the logic to look for the "highest applicable version" of each IU rather than systematically proposing the highest version. I would assume that if we were to really provide frequent updates, then users would use the check for updates. Now on the details of remediation and p2 resolver. I agree that the remediation can be slow, and this is dependent on the number of repos you have enabled. Then there is the uncompressible time it takes to resolve dependencies and figure out the solutions and for this whether the repos are validated or not does not matter. The p2 resolver has been built to deal with inconsistent repository content , and it has been proven to scale by participating in dependency resolver competitions. So to answer your question, you can give a mess of dependency and p2 will still figure out something. From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink Sent: July-03-13 5:40 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle Hi P2's remediation is very impressive but unfortunately it is dreadfully slooow. If the repo is not validated, every user is going to have to have a tea break while P2 fixes things up. And if the repo is unvalidated, there will be a lot of fixing up. I would be amazed if P2 could sort out the anarchy. So the users will wait a long time, get given an irritating please confirm this magic solution that excludes your favourite product dialog. Eclipse will become a laughing stock. Regards Ed Willink On 03/07/2013 10:31, Pascal Rapicault wrote: I like the approach of everybody contributing their latest release to a new kind of repo. However I'm wondering what happens when the dependencies are not aligned. For example GEF ships a new version but GMF ranges don't allow for it. Does the repo contain two versions of GEF or is GMF not included? Now if we step back, the issue I'm describing is caused by the fact that the release repo is validated (validated means all the IUs in the repo can be installed together, to the exception of a couple IUs) in order to reduce the number of install time dependency resolution errors. However I'm thinking that now that p2 has the remediation mechanism , the necessity to have a validated repo is lessened since at install time p2 will figure out the right set of things to install (as well as things to uninstall and update), and in the case of a check for updates it will only propose the versions that can work together. The advantage of shipping a non validated repo is that it reduces the burden of integration since the process of creating the repo is just a mirroring one. All that said, I think that in addition to this new repo, there would still be value in creating a release repo where the content is validated and more stable. Finally another thing to consider is which repo would users build against? From: cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Dennis Hübner Sent: July-03-13 2:57 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] 6 month release cycle All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it's out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away. Finally a good idea! I think this is exactly what projects and users want. Being up-to-date makes aggregation repositories (look at maven central) valuable. Best regards, Dennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2013.0.3345 / Virus Database: 3204/6458 - Release Date: 07/02/13
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
