Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNF versionlocks are ignored #817

Open
brianjmurrell opened this issue Jan 23, 2022 · 2 comments
Open

DNF versionlocks are ignored #817

brianjmurrell opened this issue Jan 23, 2022 · 2 comments
Labels
bug Something isn't working

Comments

@brianjmurrell
Copy link
Contributor

Actual behavior
dnf versionlocks are ignored.

To Reproduce
Steps to reproduce the behavior

  1. On an EL7.9 system, dnf versionlock a package
  2. Run leapp [pre]upgrade
  3. Observe that the versionlocked package got (or would get) upgraded

Expected behavior
A DNF versionlock should be obeyed and leapp should not upgrade that package any more than dnf normally should.

System information (please complete the following information):

  • OS and version: CentOS 7.9
  • Linux server.interlinx.bc.ca 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
  • leapp-0.12.1-100.20210924142320684911.master.28.g1f03432.el7.noarch
    leapp-upgrade-el7toel8-deps-0.14.0-100.202109271224Z.b7ebfca.master.el7.elevate.noarch
    leapp-upgrade-el7toel8-0.14.0-100.202109271224Z.b7ebfca.master.el7.elevate.noarch
    leapp-deps-0.12.1-100.20210924142320684911.master.28.g1f03432.el7.noarch
    python2-leapp-0.12.1-100.20210924142320684911.master.28.g1f03432.el7.noarch
    leapp-data-almalinux-0.1-2.el7.noarch
@brianjmurrell brianjmurrell added the bug Something isn't working label Jan 23, 2022
@pirat89
Copy link
Member

pirat89 commented Jan 25, 2022

Actually this is ok, as no-version locks are allowed and people are required to drop all their version locks before the in-place upgrade regarding official documention we created for RHEL upgrades. As well, right now the configuration of YUM is handled to be used during in-place upgrade for dnf - if I remember well - as most people use just yum on rhel 7.

If some packages should not be upgraded, right now the exclude has to be inside the main yum configuration, but we do not expect to treat any issues related to excluded packages neither. To me, it seems more you would like to report RFE to preserve DNF configuration from the old system instead of the yum one. That makes sense, but not sure what could be the right way to handle this. e.g. in case the yum already would contain symlinks to dnf dirs before the upgrade already, I guess this could resolve the problem - in the meaning as a workaround people can do if they are not interested in yum anymore.

I am thinking about close this one, but I am keeping it opened so others can add their thoughts (@oamg/developers : ping).

@brianjmurrell
Copy link
Contributor Author

Yeah, I guess I had switched to DNF on my EL7 machines so long ago (and use Fedora otherwise) I had forgotten that DNF wasn't even the default on EL7. I feel sorry for all of the people who have suffered through YUM on EL7 for so long and did not switch to DNF as soon as it was feasible. :-/

So I can somewhat agree with the YUM vs. DNF position. Although I also suspect I am hardly the only person to have done that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants