RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1274233 - RFE: Preupgrade assistant should filter its dependencies after upgrade
Summary: RFE: Preupgrade assistant should filter its dependencies after upgrade
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: preupgrade-assistant-el6toel7
Version: 6.8
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: ---
Assignee: Petr Stodulka
QA Contact: Alois Mahdal
URL:
Whiteboard:
Depends On:
Blocks: 1429926
TreeView+ depends on / blocked
 
Reported: 2015-10-22 10:33 UTC by Ondrej Vasik
Modified: 2019-07-01 15:36 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-01 15:36:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ondrej Vasik 2015-10-22 10:33:05 UTC 
Description of problem:

Preupgrade assistant brings relatively large portion of dependencies. It would be great to filter them out from the kickstart and to remove them with the preupgrade-assistant itself when upgrading, if the dependencies are solely to satisfy the preupgrade-assistant (e.g. to remove openscap and its deps).

Actual results: Basic system is polluted by the preupgrade-assistant deps

Expected results: After upgrade, preupgrade-assistant and its deps are removed.
Comment 2 Alois Mahdal 2017-04-04 19:47:32 UTC 
What is the current behavior?  As far as I know, preupgrade-assistant does now remove itself (actually it removes any package named "preupgrade-assistant*"), it's just that it does not remove its dependencies.

But is there even a solution to this?

The problem is that any packages that we enumerate for removal as dependency of preupgrade-assistant could be installed (and even used for production software) for reasons irrelevant to the upgrade.  That way we could easily break the system.

For example, customer could have production software using say, openscap[1].  Now they install p-a, run upgrade and ... oops, openscap is gone?

This becomes even worse when thinking about modules' dependencies since there are things that we require by asking user to install them manually[2].

~

  [1]: Note that we don't currently require that customer's production software
       even uses RPM, let alone declares its dependencies properly.

  [2]: There was solution suggested for this a year ago on ML, though--see
       solution E:

        http://post-office.corp.redhat.com/archives/rhel-inplaceupgrades/2016-February/msg00005.html
Comment 3 Petr Stodulka 2017-04-05 07:02:55 UTC 
Hi Lojzo,

Current behaviour:
  - removed are packages preupgrade-assistant* - including packages which
       are not at this moment - I guess this should be fixed too and
       somewhere is reported BZ already for this
  - now are removed really just preupgrade-assistant* rpms, without
       dependencies; we should check - e.g. using yumdb? - what packages
       have been installed with preupgrade-assistant (+modules)
       as dependencies; e.g. when openscap has been installed together
       with preupgrade-assistant, we could remove it too. if openscap has
       been installed earlier, we should keep it.

About additional requirements when user has to install some rpms manually,
there was my answer, which is still valid:

http://post-office.corp.redhat.com/archives/rhel-inplaceupgrades/2016-February/msg00006.html

About E: I don't remember another response. Still, the user will have to install
additional subpackages manually again. I can imagine, that users will not be
happy from this change, but it's discussable.
Comment 4 Petr Stodulka 2019-07-01 15:36:31 UTC 
Closing this bugzilla as the component is under a maintenance mode in which the maintainers are going to fix only critical bugs. If you consider the bugzilla critical, feel free to reopen the bug with an explanation.
Note You need to log in before you can comment on or make changes to this bug.