by Dietrich Schmitz
When I wrote YUM vs. APT: Which is Best, I didn't think it would garner 259 Google Plus votes, nor did I anticipate that it would draw nearly 4,000 pageviews and so many comments.
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,
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:
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:
Veteran programmer and yum expert +Norbert Varzariu fired back a quick reply:
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.]
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 ... | 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 ~ $
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!: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.]
