Bug 1286877 - Cannot specify package installation versions without including epoch using DNF
Cannot specify package installation versions without including epoch using DNF
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
25
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: rpm-software-management
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On: 1229730
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-30 20:14 EST by William Hopper
Modified: 2017-04-10 11:43 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-10 11:10:14 EDT
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 William Hopper 2015-11-30 20:14:52 EST
Description of problem:

In Fedora 22 and 23, `man dnf` describes the format with which one should be able to install a specific version of a package. It lists the following options:

       · name.arch
       · name
       · name-[epoch:]version-release.arch
       · name-[epoch:]version-release
       · name-[epoch:]version

As is the case with Yum, epoch is listed as being optional here. However, when trying to install a package which utilizes the epoch field, such as tomcat-1:8.0.26-1.fc23.noarch (fedora 23), DNF fails to locate the package when specifying a version *unless* the epoch is provided. This means that several of the listed options for specifying a package version don't actually work.

I.e, `dnf install tomcat-8.0.26-1.fc23.noarch` doesn't work *unless* I add the epoch '1:'. Yum doesn't have this problem, and will automatically pick the newest epoch if the package has one and the user doesn't specify it when installing.

Version-Release number of selected component (if applicable):
1.0.0 (F22) and 1.1.3 (F23).

How reproducible:

This is easily reproducible by trying to install a specific version of a package which includes an epoch. Note that the problem doesn't exist if using a package which doesn't use the epoch field. Tomcat is a good example.


Steps to Reproduce:
1. `man dnf` to verify ways which a version of a package can be installed, as is listed above.
2. `dnf install <package-version-release.arch> using a package which has an epoch, without including an epoch in this command. I.e, `dnf install tomcat-8.0.26-1.fc23.noarch`. This will fail.
3. Then run the exact same command again, but include the epoch. I.e, `dnf install tomcat-1:8.0.26-1.fc23.noarch`. This will succeed.

Actual results:

DNF is unable to find the tomcat package when an epoch is not specified in the version string.

Expected results:

DNF should automatically find the newest epoch (1 in this case) and install the package if an epoch is not explicitly provided to DNF. (At least, this is what Yum seems to do).

Additional info:
Comment 1 William Hopper 2015-12-01 14:18:42 EST
For posterity and a bit of extra color, the following are DNF commands which do and do not work when installing {{tomcat-1:7.0.59-4.fc22.noarch}}.

tomcat-1:7.0.59-4.fc22

Thus, for tomcat we have:
* Name: tomcat
* epoch: 1
* version: 7.0.59
* release: 4.fc22
* arch: noarch

According to man DNF, the following are valid ways to install packages:

       · name.arch
       · name
       · name-[epoch:]version-release.arch
       · name-[epoch:]version-release
       · name-[epoch:]version

# Based on this, the following *should* work:

dnf install tomcat.noarch
dnf install tomcat
dnf install tomcat-1:7.0.59-4.fc22.noarch
dnf install tomcat-7.0.59-4.fc22.noarch
dnf install tomcat-1:7.0.59-4.fc22
dnf install tomcat-7.0.59-4.fc22
dnf install tomcat-1:7.0.59
dnf install tomcat-7.0.59
{noformat}


Working invocations

dnf install tomcat.noarch
dnf install tomcat
dnf install tomcat-1:7.0.59-4.fc22.noarch
dnf install tomcat-1:7.0.59-4.fc22
dnf install tomcat-1:7.0.59



Failed invocations
dnf install tomcat-7.0.59-4.fc22.noarch
dnf install tomcat-7.0.59-4.fc22
dnf install tomcat-7.0.59

Thus, anything which tries to provide the version but not the epoch fails. Every example listed in Yum's man page works correctly for a package which uses an epoch.
Comment 2 Honza Silhan 2015-12-14 08:25:20 EST
Thanks for the report, we'll take a look.
Comment 3 Fedora Admin XMLRPC Client 2016-07-08 05:32:36 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Fedora End Of Life 2016-07-19 14:33:09 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 5 Igor Gnatenko 2016-07-19 18:48:52 EDT
looks like still actual.
Comment 6 Jan Kurik 2016-07-26 01:00:47 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.
Comment 7 Steve Kuznetsov 2016-09-09 10:11:45 EDT
Can confirm that I see this on F24.
Comment 8 Jaroslav Mracek 2017-04-10 11:10:14 EDT
The problem cannot be reproduced with dnf-2.2.0-1 that was released for rawhide and fc26. We provide testing repository with latest dnf versions for fc24 and later.
Comment 9 Jaroslav Mracek 2017-04-10 11:43:25 EDT
Testing repository: "dnf copr rpmsoftwaremanagement/dnf-nightly"
Comment 10 Jaroslav Mracek 2017-04-10 11:43:47 EDT

Testing repository: "dnf copr enable rpmsoftwaremanagement/dnf-nightly"

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