This upstream fix, which is basically a single line addition:
https://github.com/rpm-software-management/dnf/pull/1825/files
is very important to us because it broke livecd-creator and we're trying to build live CDs on F35. I'd like to therefore backport it to dnf in Fedora 35+.
However dnf is obviously a very important, core package, so I also don't want to risk breaking things. I believe the risk of breaking things is minimal. It might imperceptibly slow things down, worst case.
What do you think?
Rich.
On Thu, Apr 28, 2022 at 7:35 AM Richard W.M. Jones rjones@redhat.com wrote:
This upstream fix, which is basically a single line addition:
https://github.com/rpm-software-management/dnf/pull/1825/files
is very important to us because it broke livecd-creator and we're trying to build live CDs on F35. I'd like to therefore backport it to dnf in Fedora 35+.
However dnf is obviously a very important, core package, so I also don't want to risk breaking things. I believe the risk of breaking things is minimal. It might imperceptibly slow things down, worst case.
What do you think?
It seems reasonable to me.
* Richard W. M. Jones:
This upstream fix, which is basically a single line addition:
https://github.com/rpm-software-management/dnf/pull/1825/files
is very important to us because it broke livecd-creator and we're trying to build live CDs on F35. I'd like to therefore backport it to dnf in Fedora 35+.
However dnf is obviously a very important, core package, so I also don't want to risk breaking things. I believe the risk of breaking things is minimal. It might imperceptibly slow things down, worst case.
What do you think?
Isn't this a bit of a gross hack? I mean, if the DnfSack object needs to be closed, should this be done explicitly?
Thanks, Florian
On Thu, Apr 28, 2022 at 01:40:20PM +0200, Florian Weimer wrote:
- Richard W. M. Jones:
This upstream fix, which is basically a single line addition:
https://github.com/rpm-software-management/dnf/pull/1825/files
is very important to us because it broke livecd-creator and we're trying to build live CDs on F35. I'd like to therefore backport it to dnf in Fedora 35+.
However dnf is obviously a very important, core package, so I also don't want to risk breaking things. I believe the risk of breaking things is minimal. It might imperceptibly slow things down, worst case.
What do you think?
Isn't this a bit of a gross hack? I mean, if the DnfSack object needs to be closed, should this be done explicitly?
Closing it doesn't help. Because of circular references the objects don't get cleaned up until the Python generational GC runs, either because you call gc.collect() here or some unpredictable time later.
The alternative to this patch is for every caller (eg. livecd-creator in this case) to call gc.collect(), and more importantly to _know_ that they need to call gc.collect() in order that final writes to the disk to happen.
Rich.
On Thu, Apr 28, 2022 at 12:34:48PM +0100, Richard W.M. Jones wrote:
This upstream fix, which is basically a single line addition:
https://github.com/rpm-software-management/dnf/pull/1825/files
is very important to us because it broke livecd-creator and we're trying to build live CDs on F35. I'd like to therefore backport it to dnf in Fedora 35+.
However dnf is obviously a very important, core package, so I also don't want to risk breaking things. I believe the risk of breaking things is minimal. It might imperceptibly slow things down, worst case.
After testing this locally, I pushed the fix to Rawhide.
I'll wait for a while on the other branches in case we get reports of problems.
Rich.
On Thu, Apr 28, 2022 at 06:01:13PM +0100, Richard W.M. Jones wrote:
On Thu, Apr 28, 2022 at 12:34:48PM +0100, Richard W.M. Jones wrote:
This upstream fix, which is basically a single line addition:
https://github.com/rpm-software-management/dnf/pull/1825/files
is very important to us because it broke livecd-creator and we're trying to build live CDs on F35. I'd like to therefore backport it to dnf in Fedora 35+.
However dnf is obviously a very important, core package, so I also don't want to risk breaking things. I believe the risk of breaking things is minimal. It might imperceptibly slow things down, worst case.
After testing this locally, I pushed the fix to Rawhide.
I'll wait for a while on the other branches in case we get reports of problems.
I don't see loads of emails complaining about dnf being broken, so:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-f80ac5a5b4 (F36) https://bodhi.fedoraproject.org/updates/FEDORA-2022-ba4c6cf44a (F35)
Rich.