Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yum is dead, long live DNF

dnf.baseurl.org

Post reply on HN
Print view View original

111–120 of 128 posts

Re: Yum is dead, long live DNF

#111

Post by mpdehaan2 »

raverbashing wrote: post #104
ploxiln wrote: post #101

Earlier quoted context omitted.

I've worked on a large website where all backend servers were running RHEL5. We had pretty good tooling, deployment, config management. We could launch and kill new physical and virtual servers with particular "roles". We did not, however, re-image servers for every deploy. Our deployment/configuration-management would make sure the correct versions of all things were installed, including stand-alone code, services u…

Thank you. Today's "continuous deployment" world, that just "tear down and put the latest version" once a week is crazy. A stable foundation is important, and updating it without breaking everything is needed sometimes.

> "A stable foundation is important"

It all depends on what kind of apps you are deploying and supporting. While I wasn't even discussing immutable systems in this capacity, some workflows work better for .com style applications. In a typical bank environment where you have thousands of legacy applications floating around, you are more apt to not be able to control the architecture and need to push out security updates.

In place updates here are fine, however, I still wouldn't want to do an in-place dist-upgrade across all of those systems, and then find out which ones of those thousand applications had problems. In this case, it's better to redeploy those applications if they need a new OS and the OS is no longer recieving security updates - and try to shift some of that burden onto those who maintain the application.

If you are just deploying a .com app though, you need a good backup/DR strategy, and it helps to be able to redeploy everything and take steps to not get attached to state on that machine.

Re: Yum is dead, long live DNF

#112

Post by jdoss »

mpdehaan2 wrote: post #67
SwellJoe wrote: post #37

I may be a sentimental old fool, but I feel a vague sense of sadness at the removal of yum. Seth Vidal, the original author of yum (or, the fellow who forked it from Yellow Dog Updater, and made it yum), was one of the sweetest, brightest, and most helpful developers I've interacted with in my long history with Open Source. He was killed a few years back when he was hit by a car while cycling, and yum has never quite…

Ditto. I mess Seth a great amount and this too makes me sad a bit -- though his code and advice lives on in scores of people. His belief in Ansible being a decent idea really kept me going with it after the first 2 months or so, otherwise I might not have continued it as a side project, and over the course of several years, he helped me a ton with various issues and was an amazing sounding board, including sharing a…

Thank you for not giving up on Ansible at the start. It's great stuff and it enables people to do some pretty cool things.

Re: Yum is dead, long live DNF

#113

Post by wtallis »

tanderson92 wrote: post #95
wtallis wrote: post #93

Earlier quoted context omitted.

There's no way that Exherbo's package repos are anywhere near as well maintained and broad as the distros that people have actually heard of. There's no silver bullet for that problem; the only solution is manpower that they don't have.

Exherbo's package repos are incredibly well-maintained. What is provided generally always works and things are kept very much up to date (KDE/gnome/chrome/firefox updates within 24 hours usually). Lack of public awareness doesn't always mean the system isn't as well maintained as a system like gentoo (which often breaks!) The broadness of the system isn't quite as vast as many distributions but running a desktop / de…

If you haven't encountered packages missing from their repo, then their search must be broken. In just a few minutes of searching, I found that they seem to be missing anything GIS-related, netperf, smokeping, targetcli, any daap server. That's just stuff I've been using my Linux box for in the past month, but it seems like Exherbo would make me do at least as much work as something like MacPorts!

Re: Yum is dead, long live DNF

#114

Post by skorgu »

justsomeon3 wrote: post #100
darkstalker wrote: post #20

Earlier quoted context omitted.

Everyone should switch to Portage. It's like a superset of every package manager.

If we're going to be one-upping each other, then let me suggest Nix, a superset of Portage. It has many of the strengths of Portage, and even go beyond (it builds from source, and users may configure package dependencies, like USE flags on steroids -- its declarative language used to write packages is also used to configure them, so you can do more than just passing flags to a package). But it offers a substantial ad…

Are there any guidelines/docs on running Nix in an existing distro? I'd love to play around with it without having to switch the whole world.

Re: Yum is dead, long live DNF

#115

Post by tanderson92 »

wtallis wrote: post #113
tanderson92 wrote: post #95

Earlier quoted context omitted.

Exherbo's package repos are incredibly well-maintained. What is provided generally always works and things are kept very much up to date (KDE/gnome/chrome/firefox updates within 24 hours usually). Lack of public awareness doesn't always mean the system isn't as well maintained as a system like gentoo (which often breaks!) The broadness of the system isn't quite as vast as many distributions but running a desktop / de…

If you haven't encountered packages missing from their repo, then their search must be broken. In just a few minutes of searching, I found that they seem to be missing anything GIS-related, netperf, smokeping, targetcli, any daap server. That's just stuff I've been using my Linux box for in the past month, but it seems like Exherbo would make me do at least as much work as something like MacPorts!

Perhaps my needs are just different from yours. What I did say was "I have never encountered a package not available that I needed". That is not contradicted by your example. Your needs are different, that's cool. What isn't cool is claiming that the search is broken because I haven't found the need to search for those packages.

Exherbo may not be for you. It values users who are willing to be developers as well, and augment the system with the packages they need. You want others to do the work for you, that's not what Exherbo is about.

Besides, the original discussion concerned what package management system was best, not if it had tool X, Y or Z that you claim is very often needed.

Re: Yum is dead, long live DNF

#116

Post by vidarh »

baghira wrote: post #82
vidarh wrote: post #80

Earlier quoted context omitted.

apt-rpm has been around for more than a decade, and was considered for Fedora back in the day (it lost out due to a combination of lack of multilib support back then, and considerations over complexity). Last time I used Fedora it was available in the repository and worked just fine - I always preferred it over yum, despite also preferring RPM over Deb.

I thought apt-rpm was basically dead, happy to read that it is still around. And yes, I reckon the second part of my comment was wrong, you can have apt on top of .deb .

Well, you may be right it's basically dead - checking out the repository there appears to have only been one commit or so in the last two years. It may still work, but it's certainly not getting more features.

It's a shame, though - apt-rpm worked very well.

Re: Yum is dead, long live DNF

#117

Post by robto »

skorgu wrote: post #114
justsomeon3 wrote: post #100

Earlier quoted context omitted.

If we're going to be one-upping each other, then let me suggest Nix, a superset of Portage. It has many of the strengths of Portage, and even go beyond (it builds from source, and users may configure package dependencies, like USE flags on steroids -- its declarative language used to write packages is also used to configure them, so you can do more than just passing flags to a package). But it offers a substantial ad…

Are there any guidelines/docs on running Nix in an existing distro? I'd love to play around with it without having to switch the whole world.

I found this blog really helpful:

http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-sho...

It's a series that walks you through setting up and using nix. It found it really simple and satisfying - I now use nix on Ubuntu.

Re: Yum is dead, long live DNF

#118

Post by TheLoneWolfling »

Dewie3 wrote: post #107
TheLoneWolfling wrote: post #96

Earlier quoted context omitted.

It's the CADT model of software development, as usual. http://www.jwz.org/doc/cadt.html

It's kind of sad if most programmers think that debugging isn't fun. I thought that was a very large part of the programming process? Or maybe people just do OSS in order to re-balance their programming more to the side of clean-slate programming.

Some debugging can be fun. But not all of it.

There are always things that won't be fun, and those are the things that get kicked to the curb.

Re: Yum is dead, long live DNF

#119

Post by zanny »

baghira wrote: post #58
zanny wrote: post #49

Earlier quoted context omitted.

Arch always posts breaking changes to its mailing list. If you are complaining about the bleeding edge part, that really has nothing to do immediately with pacman as a package manager, you could always pull a Manjaro with real package introspection to keep tabs on incoming software. The only real missing piece of pacman is that there is no distinction between a feature and security / bugfix update. But then you shoul…

To be clear: I also am an Arch user (albeit not exclusively). I'm not complaining about the bleeding edge part (from your answer I get the feeling you already had similar discussions, with people complaining "upgrade X broke my system"). What i was driving at is the fact that pacman, as it is, does not cover the whole use case of other distros. Would you take debian, with its three branches, and move it to pacman? No…

You can pin packages in pacman, you just add them to the IgnorePkg list. And while pacman does not have a native rollback command, it does not delete any historical version of a downloaded package by default - you can set it to delete, say, 3 versions and older if you want. But you can just reinstall an old version and blacklist the package until its fixed if something goes wrong.

And that kind of operation could be automated - its just a pacman -U on the old version and append into pacman.conf on the IgnorePkg line.

And nothing really stops you from having, with pacman, repos the way Ubuntu does - because really, its not that security and feature updates are hugely segregated - they usually are just a boolean in the package description. What happens is they have repositories of software they will not update with feature releases but instead only ship bugfix and security patches for, and they just call them jesse / wheezy / vivid / wiley etc. You could use pacman for the same end, making a repository of software you don't push feature changes to but just push bugfixes in, and again replace Archs repos.

The point I'm trying to make is there is a distinction between Archlinux the repository and Pacman the package manager. You can get around a lot of the unfavorable aspects of how Arch does packaging by doing it yourself. Of course it makes no sense to actually do that when Debian, CentOS, and Ubuntu LTS exist to do that exact same job without all the work, but it isn't because pacman is crippled in one aspect of package management to such a degree its unusable for that purpose.

Re: Yum is dead, long live DNF

#120

Post by zanny »

gh02t wrote: post #83
zanny wrote: post #35

Earlier quoted context omitted.

I just made my first pkgbuild yesterday and threw it on the AUR. Having come from, first, using launchpad (eech) to using the OBS (blargh) how are pkgbuilds not "the final solution" again? They are incredibly fantastic to write and use.

PKGBUILDs and the AUR are great, but I really wish they had a spot on the AUR page for people to add extra info particular to the that package. For instance, if you come across the package in the AUR 'firefox-toast' (made up example), there is no place on the AUR page to add a description that says something like "firefox built with support for toasters." The only place to describe package customizations is in the na…

The AUR page is always completely generated by the pkgbuild. You cannot edit any of the fields yourself, you just have to upload a new source archive. In the pkgbuild you are talking about the pkgdesc field, and it is not that hard to paste a quotes wrapped string on a line in there for a description...
Post reply on HN