Ubuntu (or debian): apt-get auto-remove?
After my update from Ubuntu 12.04 to 14.04, apt-get tells me that there are a lot of packages that apt-get auto-remove could remove. Is that safe? What is the underlying idea? I think that it removes things that were added due to dependencies where those dependencies no longer exist. In the back of my mind, I worry that sometimes dependencies might be things that I wanted independently of why they were installed, but I'm not sure of that. Do people fine apt-get auto-remove works great or do you find that it throws a few babies out with the bathwater?
| Subject: [GTALUG] Ubuntu (or debian): apt-get auto-remove? That should be "autoremove". Sorry.
I wouldn't completely trust autoremove, as once it tried to automatically remove X-related packages from my desktop system. I figured the way autoremove works -- it gives a best guess of what is not needed, but that guess can sometimes be wrong, you should always review the package list and be extra suspicious when apt-get tries to remove hundreds of packages. Generally, system works well for removing old versions of libraries. If autoremove is nagging you too much -- just run 'apt-get install <packagename autoremove doesn't like>' and that will solve the problem. Nothing will get installed or removed but the package will be ignored by autoremove in the future. Alex. On 13/08/15 10:57 AM, D. Hugh Redelmeier wrote:
After my update from Ubuntu 12.04 to 14.04, apt-get tells me that there are a lot of packages that apt-get auto-remove could remove.
Is that safe? What is the underlying idea?
I think that it removes things that were added due to dependencies where those dependencies no longer exist. In the back of my mind, I worry that sometimes dependencies might be things that I wanted independently of why they were installed, but I'm not sure of that.
Do people fine apt-get auto-remove works great or do you find that it throws a few babies out with the bathwater? --- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
On Thu, Aug 13, 2015 at 11:04:39AM -0400, Alex Volkov wrote:
I wouldn't completely trust autoremove, as once it tried to automatically remove X-related packages from my desktop system.
I figured the way autoremove works -- it gives a best guess of what is not needed, but that guess can sometimes be wrong, you should always review the package list and be extra suspicious when apt-get tries to remove hundreds of packages. Generally, system works well for removing old versions of libraries.
There is no guessing involved. Now if you remove something somehow that means the rest of your desktop is no longer explicitly installed or required by something explicitly installed, then yes it will think it should be removed, since that is in fact correct for the currently requested packages. Simple enough to fix by just saying: -- Len Sorensen
On Thu, Aug 13, 2015 at 10:57:09AM -0400, D. Hugh Redelmeier wrote:
After my update from Ubuntu 12.04 to 14.04, apt-get tells me that there are a lot of packages that apt-get auto-remove could remove.
Is that safe? What is the underlying idea?
Yes. The idea is that libraries and such that were dependancies of foo version x and no longer needed by foo version y, so nothing depends on them anymore, and since you did not explicitly ask for them to be installed (they were installed automatically to solve dependancies) they can now be removed.
I think that it removes things that were added due to dependencies where those dependencies no longer exist. In the back of my mind, I worry that sometimes dependencies might be things that I wanted independently of why they were installed, but I'm not sure of that.
Do people fine apt-get auto-remove works great or do you find that it throws a few babies out with the bathwater?
It has never failed me. -- Len Sorensen
On 13/08/15 11:06 AM, Lennart Sorensen wrote:
On Thu, Aug 13, 2015 at 10:57:09AM -0400, D. Hugh Redelmeier wrote:
After my update from Ubuntu 12.04 to 14.04, apt-get tells me that there are a lot of packages that apt-get auto-remove could remove.
Is that safe? What is the underlying idea?
Yes. The idea is that libraries and such that were dependancies of foo version x and no longer needed by foo version y, so nothing depends on them anymore, and since you did not explicitly ask for them to be installed (they were installed automatically to solve dependancies) they can now be removed.
I think that it removes things that were added due to dependencies where those dependencies no longer exist. In the back of my mind, I worry that sometimes dependencies might be things that I wanted independently of why they were installed, but I'm not sure of that.
Do people fine apt-get auto-remove works great or do you find that it throws a few babies out with the bathwater?
It has never failed me.
Agreed. The only way in which it's (rarely) a pain is if you accidentally uninstalled a package that then uninstalls another package, messing with your intended setup... e.g. common example is (was?) trying to remove Evolution, which is a depenedency of some GNOME stuff. So if you uninstall Evolution, then it uninstalls some GNOME metapackages, and then a bunch of other GNOME packages which you still might want are suddenly "no longer required" because you don't have the meta package. But the problem there is not with autoremove, it's with the fact that GNOME requires Evolution. autoremove's behaviour is useful there; the Evolution dependency is the PITA. Why don't you just see what packages it's going to uninstall? Usually it lists them, but you can also run something like: `sudo apt-get autoremove --dry-run` I've almost never had a problem (I can't remember a specific case). But if you do, you can then just mark the packages you want to keep as manually install (by running `sudo apt-get install packageiactuallywanttokeep`), and then go back to autoremove. Also, worst-case scenario, you can just reinstall a package.
On 15-08-13 10:57 AM, D. Hugh Redelmeier wrote:
Do people fine apt-get auto-remove works great or do you find that it throws a few babies out with the bathwater?
I have not yet had a problem where autoremove made something go away which I still needed. If in doubt, get the list of packages that will be removed and look them up in Synaptic to see if any of them are something you think you are currently using, or are likely to be using soon. -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful!" #include <disclaimer/favourite> | --Chris Hardwick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been using this script to update, dist-upgrade, autoremove, and autoclean all in one command. Hasn't burned me yet, running it on Debian 8, LMDE, Ubuntu 12.04, Ubuntu 14.04, and Ubuntu 14.10. - --Bob, who one of these days needs to settle on a single distro ===== update script ===== #! /bin/bash # Program: update # Purpose: Perform 4-step apt-get update, dist-upgrade, autoremove and autoclean # Author: Bob Jonkman # Date: 22 March 2012 echo "Update:" apt-get update if [ $? != 0 ] ; then exit fi echo "Upgrade:" apt-get -y dist-upgrade if [ $? != 0 ] ; then exit fi echo "Auto-remove:" apt-get -y autoremove if [ $? != 0 ] ; then exit fi echo "Auto-clean:" apt-get autoclean if [ $? != 0 ] ; then exit fi if [ -e "/var/run/reboot-required" ] then echo echo "Reboot required by " cat /var/run/reboot-required.pkgs fi # EOF: update ===== Bob Jonkman <bjonkman@sobac.com> Phone: +1-519-635-9413 SOBAC Microcomputer Services http://sobac.com/sobac/ Software --- Office & Business Automation --- Consulting GnuPG Fngrprnt:04F7 742B 8F54 C40A E115 26C2 B912 89B0 D2CC E5EA On 13/08/15 10:57 AM, D. Hugh Redelmeier wrote:
After my update from Ubuntu 12.04 to 14.04, apt-get tells me that there are a lot of packages that apt-get auto-remove could remove.
Is that safe? What is the underlying idea?
I think that it removes things that were added due to dependencies where those dependencies no longer exist. In the back of my mind, I worry that sometimes dependencies might be things that I wanted independently of why they were installed, but I'm not sure of that.
Do people fine apt-get auto-remove works great or do you find that it throws a few babies out with the bathwater? --- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Ensure confidentiality, authenticity, non-repudiability iEYEARECAAYFAlXRIIQACgkQuRKJsNLM5eq04gCdEILdUAWtfLjJYF4ieiWb+svx jdQAnjxVm+u9uw/SQgMklE0wx1Y8feps =oXa2 -----END PGP SIGNATURE-----
| From: Bob Jonkman <bjonkman@sobac.com> Thanks. Here's a slightly shorter version. Picky, picky, picky. Looking gift horse in the mouth. I try to start all my scripts with "set -eu" so that more bugs will be detected. "set -e" causes the shell to exit if a command unexpectedly fails. That is, a command returns non-zero and was invoked in a non-test context. Just what you want. "set -u" tells the shell to treat a reference to an undefined parameter as an error. It will make no difference in this script. Until the script evolves more complexity. | ===== update script ===== | #! /bin/bash | | # Program: update | # Purpose: Perform 4-step apt-get update, dist-upgrade, autoremove and autoclean | # Author: Bob Jonkman | # Date: 22 March 2012 set -eu | echo "Update:" | apt-get update | | echo "Upgrade:" | apt-get -y dist-upgrade | | echo "Auto-remove:" | apt-get -y autoremove | | echo "Auto-clean:" | apt-get autoclean | | if [ -e "/var/run/reboot-required" ] | then | echo | echo "Reboot required by " I think that this should be echo -n "Reboot required by " or echo "Reboot required by" | cat /var/run/reboot-required.pkgs | fi | | # EOF: update
On Sun, 16 Aug 2015, D. Hugh Redelmeier wrote:
| From: Bob Jonkman <bjonkman@sobac.com>
Thanks.
Here's a slightly shorter version. Picky, picky, picky. Looking gift horse in the mouth.
I try to start all my scripts with "set -eu" so that more bugs will be detected.
"set -e" causes the shell to exit if a command unexpectedly fails. That is, a command returns non-zero and was invoked in a non-test context. Just what you want.
It only causes the shell to exit if a simple command fails. Best practice is not to use it at all. <http://mywiki.wooledge.org/BashFAQ/105>
"set -u" tells the shell to treat a reference to an undefined parameter as an error. It will make no difference in this script. Until the script evolves more complexity.
There's no point to using set -u after a script has been debugged. -- Chris F.A. Johnson, <http://cfajohnson.com>
| From: Chris F.A. Johnson <chris@cfajohnson.com> | It only causes the shell to exit if a simple command fails. Right. That does create some surprises. But these were all simple commands. And most of my errors are in simple commands. | Best practice is not to use it at all. | | <http://mywiki.wooledge.org/BashFAQ/105> Thanks. Useful. I respectfully disagree with the conclusion. | > "set -u" tells the shell to treat a reference to an undefined | > parameter as an error. It will make no difference in this script. | > Until the script evolves more complexity. | | There's no point to using set -u after a script has been debugged. The sad fact is that I don't know when I've gotten rid of the last bug in a script. It's really handy to have this on: I then know that most typos in parameter names will be caught so when I have a bug, I don't have to check for that kind of error myself and can concentrate on looking for other pathologies. Silently replacing a reference to a non-existent parameter with nothing is just dumb human engineering. I cannot find the Hoare quote that I'm looking for, but this seems to be a mangled version of it: Once said that removing type checking from your running programs and using them only for testing is like wearing a life jacket on your practice emergency drills and taking them off as soon as your ship was really sinking. <http://blog.mattcallanan.net/2010/09/tony-hoare-billion-dollar-mistake.html> Another relevant quote: a programming language designer should be responsible for the mistakes that are made by the programmers using the language (Hoare is a real great of our field.)
On 17 August 2015 at 01:42, D. Hugh Redelmeier <hugh@mimosa.com> wrote:
| From: Chris F.A. Johnson <chris@cfajohnson.com>
| Best practice is not to use it at all. | | <http://mywiki.wooledge.org/BashFAQ/105>
Sorry, late to this thread, but that page doesn't refer to -u
Thanks. Useful. I respectfully disagree with the conclusion.
| > "set -u" tells the shell to treat a reference to an undefined | > parameter as an error. It will make no difference in this script. | > Until the script evolves more complexity. | | There's no point to using set -u after a script has been debugged.
The sad fact is that I don't know when I've gotten rid of the last bug in a script.
I don't know when I've gotten the last bug in *any* language (of course I've only been programming for 44 years, so maybe I'll get to that point sometime :-). The only reason I can even *imagine* turning it off after "debugging" would be a claim for "efficiency". And to suggest that "the overhead of having the bash interpreter check this" is material is misguided (see Hugh's quotes from Tony Hoare). There are *very*, *very* few programs that need that kind of micro-efficiency, which is why I virtually never program in C or C++ anymore -- safety is so much more important. ../Dave
| From: David Mason <dmason@ryerson.ca> | | On 17 August 2015 at 01:42, D. Hugh Redelmeier <hugh@mimosa.com> wrote: | | > | From: Chris F.A. Johnson <chris@cfajohnson.com> | > | > | Best practice is not to use it at all. | > | | > | <http://mywiki.wooledge.org/BashFAQ/105> | > | | Sorry, late to this thread, but that page doesn't refer to -u That's my fault for trimming too much. Please look back to the previous message (I don't like endless non-targetted quoting). This part was about "set -e". Chris points out that the limitations of -e are not obvious and concludes that the feature is best avoided. The main non-obvious limitation seems to be that failing subshells don't cause the script to stop. Remember that pipelines include subshells. --- Talk Mailing List talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
participants (8)
-
Alex Volkov -
Blaise Alleyne -
Bob Jonkman -
Chris F.A. Johnson -
D. Hugh Redelmeier -
David Mason -
Kevin Cozens -
Lennart Sorensen