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 1728252 - dnf should not take buildtime into account when upgrading packages
Summary: dnf should not take buildtime into account when upgrading packages
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dnf
Version: 8.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 8.0
Assignee: Marek Blaha
QA Contact: Eva Mrakova
URL:
Whiteboard:
Depends On:
Blocks: 1751631 1760825
TreeView+ depends on / blocked
 
Reported: 2019-07-09 12:39 UTC by Michael Mráka
Modified: 2020-04-28 16:49 UTC (History)
12 users (show)

Fixed In Version: dnf-4.2.11-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1751631 1760825 (view as bug list)
Environment:
Last Closed: 2020-04-28 16:48:04 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
test.spec (243 bytes, text/plain)
2019-07-09 13:11 UTC, Michael Mráka
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1823 0 None None None 2020-04-28 16:49:03 UTC

Comment 1 Michael Mráka 2019-07-09 13:09:53 UTC
See also bug 1720690 and bug 1644241.

Comment 2 Michael Mráka 2019-07-09 13:11:42 UTC
Created attachment 1588724 [details]
test.spec

Comment 4 Jaroslav Mracek 2019-09-03 13:35:58 UTC
I create a patch that change decisions in libsolv: https://github.com/rpm-software-management/dnf/pull/1474.

The problem is discussed in  https://github.com/openSUSE/libsolv/issues/287 and https://github.com/openSUSE/libsolv/issues/342.

There is also related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1644241

Comment 18 Wolfgang Ulbrich 2019-09-16 08:56:33 UTC
Hmm,
for me this was a very useful feature to test changes in packages of mine without bumping rpm version, before i push changes to github or fedora git.
I use a local repo for this where i can rebuild packages with mock for testing commits.
Before dnf-4.2.8-2.fc30 i could simply use `dnf update` to install packages from my local repo to get changes without bumping package version.
Well, i agree that this behaviour can cause problems for other use cases.
But is there command line option to get this behaviour back?
Or can such a command line option be implemented?

Thanks

Comment 23 Wolfgang Ulbrich 2019-10-22 10:53:54 UTC
Any chance to answer to questions from a fedora maintainer before you cancel my needinfo request?

Comment 24 Marek Blaha 2019-10-24 07:28:29 UTC
Sorry, I missed your question.
As far as your use case is concerned - do I understand your work-flow correctly?

1. build a package into your local repository
2. test it
3. fix the bugs without changing the nevra and go back to 1.

If that is the case, you should be able to use distrosync command with narrowing down the repositories to your local one:

# dnf distrosync --repoid=<id-of-the-local-repo>

Comment 25 Wolfgang Ulbrich 2019-10-31 08:20:38 UTC
(In reply to Marek Blaha from comment #24)
> Sorry, I missed your question.
> As far as your use case is concerned - do I understand your work-flow
> correctly?
> 
> 1. build a package into your local repository
> 2. test it
> 3. fix the bugs without changing the nevra and go back to 1.
> 
> If that is the case, you should be able to use distrosync command with
> narrowing down the repositories to your local one:
> 
> # dnf distrosync --repoid=<id-of-the-local-repo>

Thanks for answering.
I am using my fedora RPMs to work on commits or testing PRs for MATE destop. And we have a lot of changes.
My work flow works like this.
1. Using RPMS for MATE developer releases from my public copr repo https://copr.fedorainfracloud.org/coprs/raveit65/MATE-1.23.x/builds/ for my local installation
eg. caja-1.23.2-1.fc30
2. with a new commit or a PR for testing i bumped version to caja-1.23.2-2.fc30 in my local dnf repo. This version i am using in my installation and i don't downgrade to to version from public copr repo.
3. New commits from Mate i simply add to caja-1.23.2-2.fc30 without bumping the version, to avoid pumping version daily.

So, for me it was very comfortable to use previous dnf version which reinstall packages with different buildtime with the `dnf update` command.
I thought to myself what a nice and useful new feature from fedora. I don't like all new features from fedora after using it a long time, but this one was amazing :)

Well, not a big deal because i can use `dnf reinstall caja* ` to test new changes for this package from my local repo.
But maybe the feature which was removed with latest dnf can be implemented as config or command line option?

Comment 31 errata-xmlrpc 2020-04-28 16:48:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1823


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