[NCLUG] Upgrade from Ubuntu 10.04 LTS to 12.04 LTS

[Bob Proulx]

Hi Vincent,

When you start a new topic of conversation please don't reply to an
existing thread and then just change the subject.  Replying means your
message is a reply to the message you are replying to and it will add
headers to cause it to thread into that discussion.  Anyone who has
killed that thread of discussion won't see your message.  You replied
to Stephen Warren's message about Fedora 17 Gnome 3.  Instead when you
want to start a new topic please simply compose a new message and send
it.  If you are going, "What's a thread?" then look at the message
threading done here in the mail archive:

  http://lists.nclug.org/pipermail/nclug/2012-November/thread.html

Also, please trim your postings.  Quoting the original material causes
the message to be ten miles long with repeats!  Please trim off the
excess.  Think of the kittens! :-)

  http://lists.nclug.org/pipermail/nclug/2012-November/010382.html

Vincent Randal wrote:
> Now back to my other question: Did I make "good" choices when
> upgrading from Ubuntu 10.04 LTS to 12.04 LTS? The choices I'm
> concerned about are: keep rather than replace config files,

That depends upon the package.  But regardless of how you answered it
you should clean up and finish the task by looking over the list of
files and either removing them (or moving them out of the way if you
want to archive them) or merging them into place.

  # find /etc -name '*.dpkg*' -print

That command will give you a list of files that were saved that were
either the previous version or the new version depending upon how you
answered the upgrade question.  For example:

If you said to keep your installed files:
  /etc/sysctl.conf.dpkg-dist

If you said to install the package files:
  /etc/sysctl.conf.dpkg-old

In either case the other file is saved for your perusal.  It is okay
to leave those files forever.  But that is like never taking out the
trash.  After a while you won't know what came from this upgrade and
what came from two upgrades ago.  Better to clean up after each
upgrade so that any files left behind are from the immediately
previous upgrade actions.

In design you shouldn't see any "conffile" upgrades unless you have
made local configuration customizations.  But a lot of packages are
slack and buggy and cause configuration noise even if you haven't made
any local changes.  Feel free to file bugs against those.  But there
are a lot of buggy packages and they change with every upgrade as new
bugs appear.  You might find it easiest just to handle it and move on.
Like the 'procps' package that contains /etc/sysctl.conf in my example
above.

At previous versions the procps package would always asks about
changes to that file even if you have made no changes.  That has been
fixed now but it is what I am using for my example since it used to be
buggy and so provides the example.  It would always ask even though no
local changes had been made.  For that I would move the new file into
place so that for the next upgrade it will be the package version.

  # mv /etc/sysctl.conf.dpkg-dist /etc/sysctl.conf

Otherwise if you keep the old version then it will always be different
for every upgrade in the future.  This means that it will always offer
it to you as a difference even if there is no difference.  I think it
is better to clean up and merge to the current package version when
possible.  In this case since any local changes I make go in a
separate file in /etc/sysctl.d/localfile.conf this file will never
have any changes for me so I can "merge" by "copying" it exactly into
place.

Let's look at a different example.  Let's look at /etc/postfix/main.cf.
(Since I am struggling to remember any good examples).  That file
lists local mail transport configuration.  You very well may need to
configure values there in order to have email working.  In that case
simply copying the new file into place isn't good.  Therefore it is my
example of a file that I would need to merge by editing.

  # emacs /etc/postfix/main.cf /etc/postfix/main.cf.dpkg-dist
  # rm /etc/postfix/main.cf.dpkg-dist

Of course I am going to use emacs.  You should use your favorite tool.
In any case the point is that I will merge the two files so that the
result is based upon the new template as much as possible so that it
is easy to merge again for the next upgrade.  Then after merging I
will remove the .dpkg-dist version of the file and then move to the
next file to merge.

If you don't care about the file at all and never make changes then
you can answer to install the new package version.  In which case it
will leave behind the .dpkg-old file.  In which case you can simply
remove the old file if you know you haven't made any changes to it.
For example I often see these that I never change but are always left
behind with a previous upgrade.  These are just examples and you will
have your own unique set of files.

  # rm -f /etc/console-tools/config.dpkg-old
  # rm -f /etc/cron.monthly/standard.dpkg-remove
  # rm -f /etc/udev/rules.d/65_dmsetup.rules.dpkg-bak

After doing a round of cleanup I repeat the find looking for files
left over that need to be merged, or removed or dealt with in some
way.  I repeate the above until the find turns up clean.

  # find /etc -name '*.dpkg*' -print

Then do the same process all over again for the "ucf" files.  The ucf
tool (Update Configuration File) is an alternative to the dpkg tool
and it leaves files with ucf names.  But otherwise it is the same
thing as far as you are concerned.

  # find /etc -name '*.ucf*' -print

When completely done with all of the cleanup there won't be any of
those files left.  That is good for starting the next upgrade cycle
because then you will know that anything that appears will be fresh
and not something left over from two upgrades ago.

If you have any questions feel free to post the file names and people
on the mailing list will certainly have had experience with them
already and can fill in needed details.

> and removing obsolete packages.

Yes.  Most obsolete packages will be either "dummy" or "transitional"
so as to change the name of the packge and can and should be removed.
For example at one time 'mktemp' was its own package.  But it got
merged into 'coreutils'.  So now there is no reason to keep a dummy
mktemp package installed.

  $ apt-cache show mktemp
  ...
  Description-en: coreutils mktemp transitional package
  ...
  Section: oldlibs

Packages like that are moved into the "oldlibs" section and most of
the package management tools will ask if they can be removed.  For the
most part it is good to remove all of the old lint like those.  If
there is something very special then you will already know about it
and can do something different.  (Such as an archaic library needed
for a closed source 3rd party proprietary program like a corporate VPN
or some such.  If you needed it you would already know about it.)

> Is it not possible to give a definite answer to this, because it
> depends on what I have installed or plan to do?

Correct.  Like needing a special library for a corporate VPN program
or some such.

> So far my system seems to be working okay. The main thing I use it
> for is building Android Open Source Project and that is working
> fine.

Then you are fine.  But cleaning up will make it easier to do the next
upgrade.

Bob