Community
Participate
Working Groups
I spoke with Ian last week about how Fedora is planning to move to using the director and p2 (over the existing dropins) approach. I'm looking for away to break apart the certain phases of what the director does, in particular, the download/install of artifacts from the modification of configuration data (e.g., bundles.info and profile information). One approach we discussed was allowing a "-phases <...>" parameter to the director. There was also discussion of modifying the director slightly to make this a bit easier, but I'm not sure of the details so we can discuss this here now.
Pascal and I talked about this and here is what we were thinking. 1. Add an option to the director (-downloadOnly). This will run the planner, create a plan, but only download the artifacts (and put them in the proper place). All other steps will be skipped. With this in place, you (RPM) could call the director twice. Once (during your installation phase) with the -donloadOnly flag. You would call it again (without this flag) during the configuration phase. Since all the artifacts are already downloaded, this will just configure them. Does this make sense?
(In reply to comment #1) > Pascal and I talked about this and here is what we were thinking. > > 1. Add an option to the director (-downloadOnly). This will run the planner, > create a plan, but only download the artifacts (and put them in the proper > place). All other steps will be skipped. > > With this in place, you (RPM) could call the director twice. Once (during your > installation phase) with the -donloadOnly flag. You would call it again > (without this flag) during the configuration phase. Since all the artifacts > are already downloaded, this will just configure them. > > Does this make sense? Yes. With the -downloadOnly flag, I'm assuming the features would be in the right place and properly unpacked? This sounds great if this is the case :)
Hum... This might be a 'processing' step, and I'm not sure exactly when this happens. All we can do is try ;-). Let me see what I can do.
Features and plugins would end up at the proper place in the proper format at the end of the download phase. The only thing that you need to be careful in using this is that you only deal with features and plugins (e.g. if there are random files (e.g. exe), then you would run into issues since these files would not be put in their proper place until later).
(In reply to comment #4) > Features and plugins would end up at the proper place in the proper format at > the end of the download phase. The only thing that you need to be careful in > using this is that you only deal with features and plugins (e.g. if there are > random files (e.g. exe), then you would run into issues since these files would > not be put in their proper place until later). We have tight control of what RPMs would end up using this so I don't envision that as a problem.
Created attachment 189512 [details] org.eclipse.equinox.p2.director.patch Here's my initial approach, which I initially thought was going to be a lot more complex but maybe I'm missing something. Essentially, we want to just exclude the CONFIGURE phase when executing the engine, right? Or is there something more here? I'm still looking at how to add tests for this option, shouldn't be that difficult once I find some decent test data for it from the existing p2 test data.
Not everything is complex with p2 :p All the tests are included in the gigantic p2.tests bundle and looking for references to the DirectorApp class should do the job.
A few notes: 1. This doesn't appear to work. At least it doesn't appear to do what you need Chris. When I run this, the bundles.info, profile, etc... is updated. 2. I don't think we should use a -downloadOnly flag. Instead, I think we should use a parameter like -downloadIU org.eclipse.cdt. The reason I don't like the flag, is because it conflicts with other parameters. For example, what does downloadOnly and -uninstall mean? I think we should use -downloadIU instead of -installIU or -uninstallIU.
Created attachment 189575 [details] Updated patch This fixes a few issues: 1. Messages are now in the messages properties 2. We don't thrown an exception when we get a -downloadOnly flag ;) 3. I configured the engine to *only* use Collect and CheckTrust This appears to do what you want Chris. Two things left: 1. A test case 2. Change from using the -downloadOnly flag to use the -downloadIU parameter instead.
Actually, thinking about it a bit more, I think the -downloadOnly flag is fine. We can protect against the -uninstallIU + downloadOnly if we want to. The reason for my change of mind is because -installIU and -uninstallIU are not mutually exclusive (at least they don't appear to be). -downloadOnly is really just a flag that affects which phases will be run.
Created attachment 189635 [details] org.eclipse.equinox.p2.director.patch An updated patch with test case.
Thanks Chris. This is released to head. It should appear in the build next tuesday.
Thanks, my only concern is to add some more tests about what happens when you run -downloadOnly and then run it without downloadOnly. I'll do some work this weekend and early next week to see how this work. I have some tests locally but would prefer if they were in p2.
(In reply to comment #13) > Thanks, my only concern is to add some more tests about what happens when you > run -downloadOnly and then run it without downloadOnly. I'll do some work this > weekend and early next week to see how this work. I have some tests locally but > would prefer if they were in p2. If you have more tests in this area, this would be great. I know how frustrating testing IApplications can be ;). Multiple runs (with different args) shouldn't be a concern in the wild, as the director.app is run as an application (new process) so no state will be shared between runs (unless there is a way to run an IApplication on an existing java process, then we should test this).
