Description of problem: Currently there are some additional packages/package groups which are added into the %packages section and are installed from the installer. See bug #192984 which requests a mechanism to do so. This RFE requests that those additional packages are not included in the %packages section but installed via %post or after the system reboots (preferred) prior to start of test cases using yum. This will give snake-workflow 100% control of what packages are installed by Anaconda (listed in install.log) and will make it possible for RTT to execute the default-package-set test case. Additional packages installed after system reboot is preferred because it will not interfere with RTT's test cases.
Notice: Legacy RHTS is soon to be retired and replaced by Beaker. As part of this migration process all RHTS bugs need to be re-verified against a Beaker instance by the cut-off date 5pm Monday April 12th UTC-4. Please confirm this bug is still relevant to Beaker by re-verifying it against the stage deployment of Beaker https://beaker-stage.app.eng.bos.redhat.com. To keep this bug open please comment on it If it has not received a comment by that date the bug will be closed/wontfix. After the cutoff date all commented bugs will be moved to the Beaker product. thank you
Hi, this is still an issue: https://beaker-stage.app.eng.bos.redhat.com/recipes/436#task1843 I propose to merge with bug #472740 and implement the fix for both of them.
We need to re-implement dependencies on harness side, to handle e.g. conflicting dependencies for tasks in single recipe... This should be part of larger task packaging rework - see Bug 554844.
(In reply to comment #3) > We need to re-implement dependencies on harness side, to handle e.g. > conflicting dependencies for tasks in single recipe... > > This should be part of larger task packaging rework - see Bug 554844. So you propose harness should be able to uninstall conflicting packages when needed?
(In reply to comment #4) Yes, it has to.
Bulk reassignment of issues as Bill has moved to another team.
Reverting to NEW to more accurately reflect current status.
Alexander, is this still needed? workflow-snake is going away, and "remote_post" and "ks_appends" allow arbitrary code execution in %post Setting the "packages" ks_meta variable also completely overrides the default templates.
(In reply to Nick Coghlan from comment #9) > Alexander, is this still needed? > > workflow-snake is going away, and "remote_post" and "ks_appends" allow > arbitrary code execution in %post > > Setting the "packages" ks_meta variable also completely overrides the > default templates. Hi Nick, does Beaker override the package selection specified in the <kickstart> tag ? This is the primary way QE specifies system and package configuration. If not changed then I think this request may be closed.
Dan, could you take a look at Alexander's Q in comment 10? That will determine what, if anything, still needs to be done for this RFE.
(In reply to Alexander Todorov from comment #10) > does Beaker override the package selection specified in the <kickstart> tag > ? This is the primary way QE specifies system and package configuration. If > not changed then I think this request may be closed. If you have a recipe with <kickstart> ... %packages some-package ... </kickstart> then Beaker uses your %packages section as given, but also appends any other packages required by the tasks in the recipe. As noted by Nick you can pass packages= kickstart metadata, but then you are on your own in terms of satisfying your tasks' requirements. I guess the original point of this RFE was to make Beaker stop using %packages to install task requirements, and to make the harness do the installation instead. That request remains unfulfilled. We are halfway there with restraint, which can install task requirements, but Beaker still always munges %packages to insert the task requirements there too (unless all the tasks in your recipe are "external" tasks).
(In reply to Dan Callaghan from comment #12) > I guess the original point of this RFE was to make Beaker stop using > %packages to install task requirements, and to make the harness do the > installation instead. That request remains unfulfilled. We are halfway there > with restraint, I also think this was the original point behind this request. Do you have a tracker bug for this wrt restraint or not? We can use the current one to track progress or I can open another one and close this one if you prefer.
Keeping this one open is fine - I just changed the title to more clearly express the intent. Perhaps a ks_meta flag would suffice?
This is implemented in restraint, should it be considered as WONTFIX for beah?