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

121–128 of 128 posts

Re: Yum is dead, long live DNF

#121

Post by ploxiln »

mpdehaan2 wrote: post #110
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…

> "Updating all server lists for every yum command was very annoying." This isn't the case. It updates information when the cache expires, so this will only happen about every 30 minutes or slow. It should also only take (usually) way less than a minute. > BTW ansible sucks for this aspect Yep, it's not meant to understand how to remove resources it doesn't know about. That being said, it feels like I've created PHP…

> This isn't the case. It updates information when the cache expires, so this will only happen about every 30 minutes or slow.

It doesn't do full downloads of files, but (as of RHEL5) it still makes HEAD requests or something, re-processes package lists (I guess apt does this too), I dunno. "-C" makes a significant difference. I want it to take less than a second to make a decision or spit out information; other package managers can do that.

EDIT: also want to say, I appreciate ansible overall, and I appreciate your attitude towards it. I've been close to a project that was good for a couple of uses, got kinda popular, and then people wanted it to be good for all purposes...

Re: Yum is dead, long live DNF

#122

Post by gh02t »

zanny wrote: post #120
gh02t wrote: post #83

Earlier quoted context omitted.

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...

Quite true, I know how they're generated. More like, I wish you could include something like an optional README file or something. Particularly for packages that require further setup. I know people often use the `install` function to do it, but it seems like I often run into packages that leave me wondering either what they do or what else I have to do to make them work.

This of course isn't necessarily a flaw in the AUR and is really more of an issue with the packagers doing a bad job.

Re: Yum is dead, long live DNF

#123

Post by mixmastamyk »

zanny wrote: post #34
lucb1e wrote: post #26

Earlier quoted context omitted.

Why?

I like it way more than apt at least. I don't have to use apt-cache, apt-get, apt-kitchensink to do what I want. Its all just subcommands of pacman. Its like vim vs nano - the later has the commands in the shell, but they aren't nearly as fast or power to use as vim if you take the time to learn it. Ironically, I use nano most of the time because I'm not terminal-locked enough to get vim muscle memory, but I use pacm…

https://pypi.python.org/pypi/apt-wrapper

Re: Yum is dead, long live DNF

#124

Post by wtallis »

tanderson92 wrote: post #115
wtallis wrote: post #113

Earlier quoted context omitted.

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…

In reply to a comment that listed the quality of the package repos as one of three major areas of concern, you said that "the all-around best choice is Exherbo's package management" and that "I'd like to think it has fixed all the problems Gentoo had".

If you can't be honest about its shortcomings, you won't be able to convince anyone to try out your pet project. It doesn't matter how reliable and trouble-free it is at managing the core of the system if it immediately degrades to "build it yourself" anytime you want to use something that's not popular enough to make the cut for a live CD.

Re: Yum is dead, long live DNF

#125

Post by tanderson92 »

wtallis wrote: post #124
tanderson92 wrote: post #115

Earlier quoted context omitted.

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…

In reply to a comment that listed the quality of the package repos as one of three major areas of concern, you said that "the all-around best choice is Exherbo's package management" and that "I'd like to think it has fixed all the problems Gentoo had". If you can't be honest about its shortcomings, you won't be able to convince anyone to try out your pet project. It doesn't matter how reliable and trouble-free it is…

Perhaps I was unclear, and if that's the reason for any confusion I am sorry. I was referring to the majority of the comment which was about portage's shortcomings (though it is also true that ebuild quality is a major problem for gentoo). I specifically was comparing portage/the Gentoo package management infrastructure (NOT the package repos per se) with Exherbo's package management infrastructure (by which I mean the package manager, alternatives handling, repositories). This is what I meant by "Exherbo's package management"; that does not mean the breadth of the repositories.

I like to think my comments were honest: I admitted that the system while technically superior does not have the breadth that larger distributions do, but that for my purposes it was sufficient. You ignored that and found some packages not currently packaged in an attempt to disprove my experiences. Furthermore I admitted that the project may not be for you since you expect different things from a distribution than many of us do. What is dishonest about any of this? I have been incredibly frank.

Besides, one of the nice things about Exherbo is that it handles the nonexistence of a package rather seamlessly. You can compile it by hand, install to a tempdir, and then have the package manager merge it directly while giving you the ability to specify information about the package (metadata, dependencies, etc.). And then of course the package manager can uninstall it when you no longer want it. This makes the problem of "build it yourself" kinda moot.

I'm not going to bother responding to the "make the cut for a live CD" remark since obviously the there are far more packages than would fit on a liveCD or liveDVD.

Re: Yum is dead, long live DNF

#126

Post by baghira »

zanny wrote: post #119
baghira wrote: post #58

Earlier quoted context omitted.

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…

We are basically agreeing. The point is not that you cannot automate pacman, but rather that other package managers automate for you, which is bound to be a virtue for some people. I personally never found the "integrated" rollback in dnf/yum particulary useful, but I've heard of enough people who used it to accept that it is a desired feature. Same goes for "dnf config-manager" for managing repositories with one command.

As far as pinning goes, however, I disagree: if you mark a package as IgnorePkg it does not get updated. You could use either naming conventions or splitting the repos up to track different repos for different packages, but it starts looking like an antipattern to me (i.e. the way you would have firefox track jessie while you are on wheezy would be by setting up your own repo only for firefox, a bit of an hassle). It's fine if you are the packager, it's a bit cumbersome if you want a stable debian box with a fresher version of django and nginx.

After all the road map for pacman 5.0 proposes hooks and a better handling of optdepends. Both can be already automated via scripts, but both would be nice to have out of the box.

Re: Yum is dead, long live DNF

#127

Post by zanny »

gh02t wrote: post #122
zanny wrote: post #120

Earlier quoted context omitted.

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...

Quite true, I know how they're generated. More like, I wish you could include something like an optional README file or something. Particularly for packages that require further setup. I know people often use the `install` function to do it, but it seems like I often run into packages that leave me wondering either what they do or what else I have to do to make them work. This of course isn't necessarily a flaw in th…

You could add a README as an external source if one is not included with the binary package or source repo itself.

And yeah I know that isn't basically a longform description field on the AUR page, but comments can do that job too. I don't see it as some crippling issue, and honestly I would probably not even change it - the way the AUR is laid out now makes it easy to pull down pkgbuilds and display package information agnostic to the environment easily. Adding paragraphs of detail into the pkgbuild or on the website limits that.

Re: Yum is dead, long live DNF

#128

Post by skorgu »

robto wrote: post #117
skorgu wrote: post #114

Earlier quoted context omitted.

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.

Cool, thanks!
Post reply on HN