Red Hat Pushing DNF 5 Into Development For Improving The Package Manager

[RahulSundaram]

It was reported in 2015, so after five years it's still unresolved.

Your post indicates that it was auto closed after it was EOL. I wouldn't be able to tell whether it was resolved or not based on that. What was the bug report number?

[mroche]

Just having some fun, I did some small tests of installation times for larger transactions in containers (ArchLinux from Docker, UBI 8 from Red Hat). The times include repo caching, downloading, and installing. "--allowerasing" was needed to get over a coreutils vs coreutils-single conflict with the UBI container.

Pacman:
$ time pacman -Syu xorg xorg-server gnome # 645 packages, 550MB download, 2.4GB installed
real 9m14.225s
user 0m44.394s
sys 0m15.765s

DNF:
$ time dnf -y groups install "GNOME" # 787 packages, 545M download, 1.7GB installed
real 4m57.101s
user 1m19.233s
sys 0m13.963s

$ time dnf -y groups install Core Fonts GNOME "Hardware Support" base-x --allowerasing # 973 packages, 898MB download, 1.8GB installed
real 7m29.249s
user 2m2.126s
sys 0m19.186s

$ time dnf -y groups install "Server with GUI" --allowerasing # 1163 packages, 1.1G download, 2.5GB installed
real 10m50.XXXs
# forgot to copy paste the result before doing a history command, lost scrollback

This is not a perfect test as in a container certain install scripts won't run properly, but the selinux ones seemed to take as long as they usually do The "Server with GUI" group on RHEL adds a bunch of other package groups than just GNOME related functionality (Common NetworkManager submodules, Container Management, Guest Desktop Agents, Hardware Monitoring Utilities, Headless Management, Internet Browser, Multimedia, Printing Client, Server product core, Standard). And of course the packages included between the two distros will be different, but it was a fun waste of an hour

Cheers,
Mike

[Volta]

Your post indicates that it was auto closed after it was EOL. I wouldn't be able to tell whether it was resolved or not based on that. What was the bug report number?

It's 1227979

[RahulSundaram]

It's 1227979

Thanks. I took a look and I couldn't reproduce that with dnf-4.2.18-1.fc31.noarch. If you are still able to see that, you might want to just open a new one against the current release with the version info and reference the old bug.

FWIW, I typically just use aliases instead of tab completion for frequently used ops. Here is my config for your reference

/etc/dnf/aliases.d/USER.conf
[main]
enabled = True

[aliases]
in = install
ri = reinstall
rm = remove
mc = makecache
up = update
dsync = distro-sync
dg = downgrade
sh = shell
se = search

[Volta]

RahulSundaram

Thanks! I'll give it later a try.

[finalzone]

Why close bugs that aren't resolved? That's so backwards. Jwz wrote about this idiotic practice 17 years ago and Fedora is still doing it even now.

Speaking as a maintainer, it is the job of the report to update their bug ticket once they received an automatic message about a related operating system support reaching EOL. Chance is a bug from an EOL system may get resolved on a newer version and maintainer would avoid wasting time.

[finalzone]

Maybe that's how it's done in your projects, but elsewhere that practice is seen as mind-blowingly stupid and dysfunctional.

Then come with a rationale and propose a better suggestion to the as long you are willing to maintain it using this page as starting point.

[skeevy420]

I used to be a Fedora package maintainer until I had enough of the stupid policies. I'm not wasting my time with it again. This "fix it yourself or you're the problem" attitude so common in the Red Hat world is so dumb. You don't need more bureaucracy and policy making, you just need to stop closing useful bug reports for no reason.

"Our OS has reached EOL status. Is this issue still relevant on the updated and supported version of our OS?"

**no-response cricket noises**

**Issue gets closed**

That seems like a decent reason to close an issue out to me.

[finalzone]

I used to be a Fedora package maintainer until I had enough of the stupid policies. I'm not wasting my time with it again. This "fix it yourself or you're the problem" attitude so common in the Red Hat world is so dumb.

Do you even realize what you wrote also applied on project including Linux kernel done by contributors volunteering their time?

You don't need more bureaucracy and policy making, you just need to stop closing useful bug reports for no reason.

We do otherwise the organization will be a total mess and will crumble for itself. Should you think one of bug report remain useful, simply change the release to the current version or Rawhide in the case of Fedora. Did you do that?