Bug 1274233 - RFE: Preupgrade assistant should filter its dependencies after upgrade
RFE: Preupgrade assistant should filter its dependencies after upgrade
Status: NEW
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: preupgrade-assistant-el6toel7 (Show other bugs)
6.8
Unspecified Unspecified
medium Severity low
: rc
: ---
Assigned To: pstodulk
Alois Mahdal
: Extras, FutureFeature
Depends On:
Blocks: 1429926
  Show dependency treegraph
 
Reported: 2015-10-22 06:33 EDT by Ondrej Vasik
Modified: 2017-05-04 04:45 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ondrej Vasik 2015-10-22 06:33:05 EDT
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 15:47:32 EDT
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 pstodulk 2017-04-05 03:02:55 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.