The amount of blustering that goes on concerning APT continues to amaze me. People are more emotional than logical when it comes to certain topics and APT is certainly held up as being 'the package manager by which others are compared'.
So, compare I did and at the end of the story I took away in summary that I have not experienced any issues using YUM in the wake of leaving the Ubuntu camp in January 2013.
To be truthful, I am now quite impressed with YUM and while by itself, APT and YUM may be on par feature equivalent, with the help of its plugin extensible architecture, YUM wins out in breadth of features when you install a few of the mentioned plugins in the story.
Yesterday, I had a situation where a colleague experienced an issue that caused loss of audio and it seems that one of the updates which had just finished installing may have been the culprit.
Here's where YUM shines bright and I thought I'd share a feature with you that will definitely be of help at some point. It's the yum history feature.
It just so happens that yum while performing updates is simultaneously running a journal transaction set recording your update to a transaction id along with all of the excruciatingly painful package update and dependency information you'd ever want to know. Most of the time, you'll never care about it. In some situations however, you may encounter a post-update problem.
The good news with yum is you have a recourse. If you need to or at the direction of your Distro's technical support team, you may be called upon to perform a rollback.
Here's how it works.
Opening a terminal window, one can determine information about the yum transaction history with,
dietrich@AOD260 ~ $ sudo yum history [sudo] password for dietrich: Loaded plugins: aliases, changelog, downloadonly, fastestmirror, filter-data, : keys, langpacks, presto, refresh-packagekit, remove-with-leaves, : rpm-warm-cache, security, show-leaves, verify Adding en_US to language list ID | Login user | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 11 | Dietrich ...Hey, that's great. So, I can readily see the transaction id (11) from April 8, 2013 which I know correlates with my issue. Let me get some detail about that. Can I? Yes!:| 2013-04-08 21:50 | Install | 2 10 | Dietrich ... | 2013-04-07 11:26 | I, O, U | 19 9 | Dietrich ... | 2013-04-06 10:11 | Install | 1 EE 8 | Dietrich ... | 2013-04-05 16:29 | I, U | 32 7 | Dietrich ... | 2013-04-01 20:33 | Install | 1 6 | Dietrich ... | 2013-04-01 20:33 | Install | 3 5 | System | 2013-04-01 18:03 | Install | 13 4 | Dietrich ... | 2013-04-01 17:58 | I, U | 7 3 | System | 2013-03-31 23:21 | Update | 1 EE 2 | Dietrich ... | 2013-03-31 22:23 | Install | 1 EE 1 | 5001 | 2013-03-25 21:03 | Install | 1305 history list dietrich@AOD260 ~ $
dietrich@AOD260 ~ $ sudo yum history list 11 [sudo] password for dietrich: Loaded plugins: aliases, changelog, downloadonly, fastestmirror, filter-data, : keys, langpacks, presto, refresh-packagekit, remove-with-leaves, : rpm-warm-cache, security, show-leaves, verify Adding en_US to language list ID | Command line | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 11 | install pavucontrol | 2013-04-08 21:50 | Install | 2 history list dietrich@AOD260 ~ $
Now, in my story example pavucontrol isn't really what caused no audio, but for the sake of simplicity, I am using it to show the rollback--you get the idea. If you had say a large update, the list would be longer, enumerating each and every discrete package in very clear terms. This is really important for the technical support staff who need a good audit trail for actions taken on any Linux system. You may take this information with 'a grain of salt', but know that this is the meat of the transaction journal detail that will allow a rollback to occur.
All well and good.
So, I have queried yum for update history, then asked for specific detail behind one transaction set (by transaction id). Now, I have identified the transaction id which I want to roll back. Here's how:
dietrich@AOD260 ~ $ sudo yum history undo 11 [sudo] password for dietrich: Loaded plugins: aliases, changelog, downloadonly, fastestmirror, filter-data, : keys, langpacks, presto, refresh-packagekit, remove-with-leaves, : rpm-warm-cache, security, show-leaves, verify Adding en_US to language list Undoing transaction 11, from Mon Apr 8 21:50:09 2013 Dep-Install libglademm24-2.6.7-3.fu14.x86_64 @fuduntu Install pavucontrol-0.9.10-2.fu2013.x86_64 @fuduntu Resolving Dependencies --> Running transaction check ---> Package libglademm24.x86_64 0:2.6.7-3.fu14 will be erased ---> Package pavucontrol.x86_64 0:0.9.10-2.fu2013 will be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: libglademm24 x86_64 2.6.7-3.fu14 @fuduntu 89 k pavucontrol x86_64 0.9.10-2.fu2013 @fuduntu 595 k Transaction Summary ================================================================================ Remove 2 Packages Installed size: 684 k Is this ok [y/N]: y Downloading Packages: Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Erasing : pavucontrol-0.9.10-2.fu2013.x86_64 1/2 Erasing : libglademm24-2.6.7-3.fu14.x86_64 2/2 Verifying : libglademm24-2.6.7-3.fu14.x86_64 1/2 Verifying : pavucontrol-0.9.10-2.fu2013.x86_64 2/2 Removed: libglademm24.x86_64 0:2.6.7-3.fu14 pavucontrol.x86_64 0:0.9.10-2.fu2013 Complete! dietrich@AOD260 ~ $
So, there you have it. It wasn't terribly difficult and had it been a larger update or even series of updates, the task of backing out, uninstalling packages might have been more than intimidating and while not impossible to do, it would have taken extra special diligence and care to perform without causing a side effect issue. This is great. The roll-back is done. Nice and tidy.
I queried on my private community about whether or not APT has something equivalent to yum history and it was for the most part met with silence. One user +Chris Ahlstrom suggested:
Ah, you can do this (requires forethought :-): dpkg --get-selections "*" > my_packages-datestamp Then later you could rollback by using that package list: dpkg --set-selections < my_packages-datestamp apt-get -u dselect-upgrade
Veteran programmer and yum expert +Norbert Varzariu fired back a quick reply:
well... not practicable at all. also, the history plugin allows operating on the transactions themselves, not just rolling back an update.I agree. More to the point, I would add that this example puts APT in a full-Nelson, to coin a wrestling term. No, correction. It's a body slam followed by a pin!
So, that's YUM for you. It is truly 'A Breed Apart'.
-- Dietrich
[Edit: I received private comments in my LA community from two distinguished and respected developers who intimate that 'code quality' for YUM is questionable and buggy. This makes me wonder to what extent other package codebases are suffering from code maintenance issues. Please feel free to comment if you have any pertinent first-hand knowledge.]
Yeah right..."YUM is so great..." that's why it's getting replaced in the next Fedora version, while APT is still moving strong and even Google have stated that .deb and apt is "leaps and bounds ahead of everything else".
ReplyDeleteFedora's new DNF is a fork of YUM 3.4 with a replaceable backend libsolver called hawkey.
ReplyDeleteEssentially yum functionality won't change--only dependency solving library routines.
So, from that standpoint, it's an update to yum, not a wholesale replacement.
Please get your facts straight.
Exactly! The single that YUM is in the need for such a major upgrade , means that it is far from being a "breed apart" as your article suggests.
ReplyDeleteI measure features not code. APT lacks rollback capability. That is a glaring deficiency in today's world.
ReplyDeleteIf yum has code issues (and it does; what package managers don't?), then the fork will sit along side of it for quite a while until it has been fully debugged. For now, no announcement has been officially made for when yum will be replaced by DNF in Fedora.
yum, code qualitative issues aside, is far more robust and by virtue of its extensibility more resilient and therefore, 'a breed apart'.
You do realize that this conclusion of yours is a subjective one. For me the mere existence of "apt-listbugs" , "apt-listchanges" , and "apt-get autoremove" set APT not one but two breeds apart.
ReplyDeleteInterestingly, zypper uses filesystem snapshots triggered as post-transaction hooks; currently only butterfs on the root partition is supported. I'm not sure how I feel about that since it is possible for other processes to also have changed files during the transaction (documentation notes to check for this, in fact) and it relies on a specific file system. One the other hand, using file system snapshoting is a compelling concept ...
ReplyDeleteNeat article, thanks for sharing, Dietrich.
"apt-get autoremove"? Seriously?
ReplyDeleteTry: sudo yum remove $(package-cleanup --quiet --leaves --exclude-bin)
"apt-listchanges"?
rpm -qi --changelog package
What's the equiv of 'yum history undo' or rpm -Vv kernel?
All software eventually needs maintenance on the scale of a rewrite. DNF is called DNF so it can be installed in parallel with YUM and debugged on a wide scale.
I agree, I find the concept of using a filesystem snapshot very compelling. I haven't dug too deeply though, I wonder how snapshot metalogs are managed.
ReplyDeleteOh my goodness yes ZFS or BtrFS snapshots are the ticket. For developers running VMs in various configurations, testing, it is a huge timesaver in troubleshooting debugging to make setting changes, test, and simply roll back when done. Not to mention the obvious 'high availability' for NAS instances.
ReplyDeleteThanks for the feedback Aaron. :)
ZFS is awesome Fewt. Checkout ZFSonLinux. It's a DKMS, not sure if you can readily set up a booting ZFS partition yet, but certainly child's play for secondary partitions.
ReplyDeleteYou got it. Thanks Mon.
ReplyDeletethe "--leaves" flag is overly eager in removing packages which are needed by the system, the "--exclude-bin" helps a bit , it does leave unecessary packages behind. All in all it is not nearly effective as APT's "autoremove" command.
ReplyDeleterpm -qi --changelog package is an rpm feature not yum specific but nevertheless it is for checking one package at a time. apt-listbugs and apt-listchanges can even be combined in the upgrade process so before you press "enter" , so can have a complete picture of the changes and the known bugs that the new packages bring along.
There is no apt equivelant to yum history undo and I've never implied that there is, but apt has excellent dependency resolving so you can bring your system to a previous "package condition" it just takes a little more time.
rpm -Vv kernel : first of all ...again an rpm command and not a yum specific (I could just start proposing dpkg ones my self you know...) . Secondly what exactly is this command? a verification one? If yes then the equivelant is "debsums -c" or "apt-get check" . It depends on what exactly the rpm command you've mentiones does.
The two tools were designed to work together so they should be used together. The right tool for the job and all that.
ReplyDeleterpm -Vv will verify and report the state of each file laid down on the filesystem by rpm. It is an extremely powerful tool that can be used to validate your entire system provided the rpmdb is not corrupt or compromised.
'apt-get autoremove' is a terribly dangerous tool (as was the command I linked) and should be avoided (which is why I said seriously?) as it has been known to devastate a computer that was working before the command was executed. :)
Ok then then both debsums -c and apt-get check are equivalents of rpm -Vv , with the exception that debsums requires the existence of buildtime generated md5sum files, while apt-get check is more generic in its checking procedure.
ReplyDeleteI do agree that both "cleaning" commands are dangerous but I've managed to wreck a lot more Fedora installations with the --leaves flag and the equivalent yum-plugin than I have done with apt's autoremove. As a matter of fact the only time that autoremove went crazy and started to propose the removal of necessary packages was on an Debian Lenny system where I've had many mixed packages from unstable, experimental, 3rd party repos, with messed up apt-pinning rules.
I do like apt, a lot. I've only really seen apt autoremove break on Ubuntu, but well enough said there. :)
ReplyDeleterpm -V is really cool if you have a chance to look at it.
http://www.rpm.org/max-rpm/s1-rpm-verify-output.html
Huh!! Apt-get !! Yum!! What is this package management you speak of?
ReplyDeleteFrom Slackware User
LOL!! I joke
Great article Mr. Schmitz
OK here's the gist of the whole thing.
ReplyDeleteWhen using RHEL, Fedora and other Redhat-based distros yum is your friend. When using Ubuntu, Mint, Debian and other Debian based distros apt-get is your friend.
Feature completeness while comparing apples (yum) and oranges (apt-get)
is irrelevant. To paraphrase My Big Fat Greek Wedding "In the end we are all
fruit".
Articles like these ones only serve sensationalism and pump up page hits
and page views because people feel strongly about their favourite tools.
Let's just snap out of it and find something more interesting and challenging to talk about, shall we?
gnome vs kde
ReplyDeletegnome-shell vs unity
ubuntu vs .......
best linux distribution of
Hurrayy.. another 4000 pageviews.
where this '' come from? disqus bug?
ReplyDeleteI would disagree. By the amount of discussion and pageviews, I'd say this is an 'interesting' topic. This is not sensationlism, but a discussion of facts which set YUM apart from APT in particular.
ReplyDeleteThanks
ReplyDeletehttp://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/
ReplyDeletefyi:
the below remarks--is not enabled in /etc/yum.conf by default
/***********
November 9, 2010
I just checked this into yum on friday. It’s currently defaulting to off but I wanted to mention it so it gets more testing.
if you set:
clean_requirements_on_remove = 1
in your yum.conf under [main]
or use:
–setopt=clean_requirements_on_remove=1
on the command line, then yum will remove no-longer-needed dependencies of pkgs that you are removing from your system.
Allow me to disagree with your disagreement. Yum transactions are one feature that is interesting. But hardly a feature that would make this "a breed apart" from any other package manager out there. It's your opinion and I respect it.
ReplyDeleteHowever this is a very trivial and subjective comparison. One can find 100s of reasons why Debian (which you condemned to oblivion) might be "breeds apart" from your favourite distro. Most will see through the subjectiveness of the topic since choosing a distro is like choosing a car.
It comes down to personal preference and whether a certain 'vehicle' fulfills your needs. Same goes for distros.
This is why it is my opinion that these kind of articles serve no purpose but to stir up traffic and if traffic is a measure of how "interesting" topics are (btw technically speaking a pageview is
just a hit on the webpage. It can be as long as 2 seconds...
doesn't mean the reader actually spends any time on it... just
that the browser visited the page) then the media (all forms of it)
are getting it wrong.
It's an analysis of what I and many consider to be an important feature, which doesn't have an equivalent in APT.
ReplyDeleteIf you don't like that, so be it. Please come up with something intelligent to say. Your remarks are off-topic.
Too bad you contradictd yourself. "[...]set APT not one but two breeds apart." vs "...and neither is apt or any other package manager". Even if you were "proven wrong" and changed your mind, the original statement shows what is wrong with this "debate". I think there is merit in pointing to the problem, but lets not delude ourselves into believing a healthy debate will change any minds. The nature of this issue is born from the inherent problem/beauty in OSS. Unless we trully understand what we are talking about before a discussion/implementation, I think it's more of a detriment.
ReplyDeleteNope, no contradiction at all. My "two breeds apart" was obviously a sarcasm to the absurd claim that yum is a breed apart. Sorry to disapoint you but since you've failed to understand my comment , your argument against me doesn't stand. Thanks for taking interest in the conversation though!
ReplyDeleteAnd I do like yum...for some of its features...but I would never set it a "breed apart" from apt or any other well-known pm manager. That was my original argument in the first place.
ReplyDeleteThanks for that information although it is outdated (2010), I am using yum-3.4.3-53 on Fedora 18 which provide autoremove functionality through that command. I am surprised "yum autoremove" is not even listed inside man yum.
ReplyDeleteI don't see it listed on yum -h, nor is it shown in the man page as you mention. So I am confused.
ReplyDeleteI see that 2 of my aswers were deleted. ...well that speaks volumes , doesn't it? Anyway I believe we've given the author the page hits he desired for this biased article so there's no need to engage in anymore conversation....especially if posts are being deleted. Good luck to rest of the conversation members. ..at least now we know the author's true colors for reference in future articles.
ReplyDeletePS. This message will also be deleted in less than 10 secs
So am I. You can view my blog:
ReplyDeletehttp://blog.thefinalzone.net/2013/04/yum-autoremove.html
Try it on a test machine with latest version of yum.
I am not sure I like a feature which has no documentation.
ReplyDeleteI think an important point to make is that YUM has parity with APT. I believe many people still think APT is superior, because they last used the RPM package format before YUM was created or before it was stable.
ReplyDeleteAlso, I think "undo" is a hugely useful feature for package managers. YUM has it. The lesser known Linux package management systems Conary and Nix also have it. I did not realize APT does not - I think the children (all inspired at least partially by APT) have outdone their parent.
Well put. Thank you Michael.
ReplyDeleteOkay that makes sense. Thanks.
ReplyDelete