Choosing dist-upgrade Over upgrade

Under Linux, the command

apt-get update

Is safe, and only refreshes the packages list stored on the client, to reflect changes that have been made in the repository. OTOH,

apt-get upgrade

Tells the package manager, simply to upgrade all packages, which have newer versions in the lists, from the versions currently installed. In principle, this sounds logically correct. But there is an alternative to this, which is called

apt-get dist-upgrade

The difference is, that ‘dist-upgrade’ is smarter than ‘upgrade‘ about global changes that might take place, due to changes in the overall Debian Distribution – hence the ‘dist’ – which can affect which directories files and configuration changes need to be stored to.

In practice, ‘d-u’ is always safer than just ‘upgrade‘, and does everything ‘upgrade’ is supposed to do. Therefore, we generally give the command

apt-get dist-upgrade

Dirk

 

How I fixed my Chrome for Linux Package Issue

In a previous posting, I described a specific issue I was having, with my Linux installation of Google Chrome.

I have now found a solution to this exact problem.

Chrome for Linux installs a daily cron job, which resets the file

/etc/apt/sources.list.d/google-chrome.list

by default. If it is absolutely necessary to override this behavior, let us say because our package manager is set up by default to pull both the 32-bit and the 64-bit contents of any repository, but the latest build of Chrome only supports a 64-bit architecture, then there is a configuration file named

/etc/default/google-chrome

This file defaults to containing


repo_add_once="false"
repo_reenable_on_distupgrade="true"

This can be changed to


repo_add_once="true"
repo_reenable_on_distupgrade="true"

Dirk

(Edit 02/06/2016 : ) Unfortunately, I have discovered that the variables defined in

/etc/default/google-chrome

Do Not change the behavior of the cron job, to rewrite the file

/etc/apt/sources.list.d/google-chrome.list

And so I found that slightly more aggressive editing was needed by be.

On standard Debian / Linux systems, the daily cron jobs associated with specific packages are stored in the directory

/etc/cron.daily

And there is a symlink in this directory, pointing to a target file, which is the script that Google Chrome runs. I did not take out the symlink. But I have changed the permission bits of the target file, to make that non-executable.

 

A Glitch with the Chrome for Linux Package Repository

One of the software packages I have installed on the computer ‘Phoenix’ is “Google Chrome”, for Debian / Linux. And this package is eligible for upgrades via Package Manager because Google makes the binaries available. In order for the upgrades to take place, an ‘apt-get update’ command needs to succeed, with this file installed:


/etc/apt/sources.list.d/google-chrome.list

One problem I’ve encountered recently, is that because my computer is set up to pull both the 32-bit and the 64-bit repositories, I get an error message telling me that there is apparently no more 32-bit version on the Google servers. And so the line of code that is needed in this file requires


deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

The only problem though with this, is that as soon as my Chrome package does update, the ‘[arch=amd64]‘ vanishes, because the package overwrites whatever modifications I made to this file.

It could be that this problem has delayed my getting updates through until now. But unless either the Chrome repository starts to include a 32-bit entry again, or until the same package replaces this file with the specification in-place, this problem will eventually recur.

Dirk