Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • finalzone
    replied
    Originally posted by ...

    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?
    Last edited by tildearrow; 08 March 2020, 03:58 PM.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by ...

    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.
    Last edited by tildearrow; 08 March 2020, 03:58 PM.

    Leave a comment:


  • finalzone
    replied
    Originally posted by ...

    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.
    Last edited by tildearrow; 08 March 2020, 03:58 PM.

    Leave a comment:


  • finalzone
    replied
    Originally posted by ...

    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.
    Last edited by tildearrow; 08 March 2020, 03:58 PM.

    Leave a comment:


  • Volta
    replied
    RahulSundaram

    Thanks! I'll give it later a try.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Volta View Post

    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

    Code:
    /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

    Leave a comment:


  • Volta
    replied
    Originally posted by RahulSundaram View Post

    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

    Leave a comment:


  • mroche
    replied
    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.

    Code:
    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

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Volta View Post

    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?

    Leave a comment:


  • Volta
    replied
    Originally posted by RahulSundaram View Post

    That's a more reasonable comment. Which part of dnf is slower for you (ie) is it the metadata downloads? IO etc and what are the issues you have with bash completion? Have you filed any bug reports for either of these?
    I made a reply, but it's currently 'unapproved'. Probably because of links. Here's citation from bugzilla:

    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.
    It was reported in 2015, so after five years it's still unresolved.

    Leave a comment:

Working...
X