Tuesday, April 9, 2013

YUM: A Breed Apart

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,

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

Enhanced by Zemanta

36 comments:

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

    ReplyDelete
  2. Fedora's new DNF is a fork of YUM 3.4 with a replaceable backend libsolver called hawkey.

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

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

    ReplyDelete
  4. I measure features not code. APT lacks rollback capability. That is a glaring deficiency in today's world.


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

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

    ReplyDelete
  6. Interestingly, 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 ...


    Neat article, thanks for sharing, Dietrich.

    ReplyDelete
  7. "apt-get autoremove"? Seriously?

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

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

    ReplyDelete
  9. Oh 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.

    Thanks for the feedback Aaron. :)

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

    ReplyDelete
  11. the "--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.

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

    ReplyDelete
  12. The two tools were designed to work together so they should be used together. The right tool for the job and all that.

    rpm -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. :)

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

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

    ReplyDelete
  14. I do like apt, a lot. I've only really seen apt autoremove break on Ubuntu, but well enough said there. :)


    rpm -V is really cool if you have a chance to look at it.


    http://www.rpm.org/max-rpm/s1-rpm-verify-output.html

    ReplyDelete
  15. Huh!! Apt-get !! Yum!! What is this package management you speak of?

    From Slackware User
    LOL!! I joke
    Great article Mr. Schmitz

    ReplyDelete
  16. OK here's the gist of the whole thing.

    When 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?

    ReplyDelete
  17. gnome vs kde
    gnome-shell vs unity
    ubuntu vs .......
    best linux distribution of

    Hurrayy.. another 4000 pageviews.

    ReplyDelete
  18. where this '' come from? disqus bug?

    ReplyDelete
  19. I 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.

    ReplyDelete
  20. http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/
    fyi:

    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.

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

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

    ReplyDelete
  22. It's an analysis of what I and many consider to be an important feature, which doesn't have an equivalent in APT.


    If you don't like that, so be it. Please come up with something intelligent to say. Your remarks are off-topic.

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

    ReplyDelete
  24. Nope, 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!

    ReplyDelete
  25. And 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.

    ReplyDelete
  26. Thanks 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.

    ReplyDelete
  27. I don't see it listed on yum -h, nor is it shown in the man page as you mention. So I am confused.

    ReplyDelete
  28. I 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.

    PS. This message will also be deleted in less than 10 secs

    ReplyDelete
  29. So am I. You can view my blog:
    http://blog.thefinalzone.net/2013/04/yum-autoremove.html


    Try it on a test machine with latest version of yum.

    ReplyDelete
  30. I am not sure I like a feature which has no documentation.

    ReplyDelete
  31. I 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.

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

    ReplyDelete
  32. Okay that makes sense. Thanks.

    ReplyDelete