[buug] converting Ubuntu to Xubuntu?

[Michael Paoli]

Question about that was asked at last BUUG meeting[0].  Thought I'd
peek into it a wee bit further.  Most notably, I was curious, does
Xubuntu use the same repositories as Ubuntu?  After all, Kubuntu and
Xubuntu are "just" different flavors/spins of Ubuntu - or at least so
I've presumed.  Well, I didn't have Xubuntu handy, but I did have
readily available Kubuntu ISO[1] ... even if an older[2] one.  So, I
rather quickly and conveniently set up and launched it "live" ("Try
Kubuntu") on a qemu-kvm virtual machine.  And I had a look at the
sources configuration for apt (since {U,Ku,Xu}buntu are .deb dpkg and
apt based, but their installations don't use the Debian repositories).
Well, as far as I can easily tell, at least for
Kubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
it uses in its apt configuration[2]:
deb cdrom:[Kubuntu 10.10 _Maverick Meerkat_ - Release i386  
(20101007)]/ maverick main restricted
deb http://archive.ubuntu.com/ubuntu maverick main restricted
deb-src http://archive.ubuntu.com/ubuntu maverick main restricted
deb http://security.ubuntu.com/ubuntu maverick-security main restricted
deb-src http://security.ubuntu.com/ubuntu maverick-security main restricted
deb http://archive.ubuntu.com/ubuntu maverick-updates main restricted
deb-src http://archive.ubuntu.com/ubuntu maverick-updates main restricted
and that's likely same - or at least same repositories, as
corresponding Ubuntu version:
Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
So, I presume similar likely applies to current Ubuntu and Xubuntu -
e.g. 12.10 or 12.04.x LTS, or any currently supported versions.

So, I'd think, at least theoretically, converting from Ubuntu to Xubuntu
should be relatively feasible with an approach approximately as follows:
o Backup :-) - one will generally always want to be able to
   recover/restore, even if thing(s) go (very) badly.  This includes also
   having suitable recovery/restore boot (e.g. media) options available -
   for fixing, recovery, or restore, as may be needed.
o update - get current installation caught up on security and critical
   bug fix updates, to a currently supported release.  Namely the apt
   sources configuration should still be pointing to a release version
   that's still supported (if not, do the operating system upgrade
   procedures to get there first).  Procedure may be a bit different for
   {U,Ku,Xu}buntu, but typically on Debian to get caught up on security
   and critical bug fix updates, something like:
   # aptitude update
   # aptitude safe-upgrade
o make sure no packages are in broken state or have any broken
   dependency issues, etc.  (The Debian release notes on upgrade
   procedure cover that well, I'd think {U,Ku,Xu}buntu has similar)
o gather and save information on installed packages:
   $ dpkg --get-selections > Ubuntu_dpkg_--get-selections
o boot "live" CD version of Xubuntu corresponding to same version of
   Ubuntu that is installed.  Use, (I presume) "Try Xubuntu".
   That should be done on same system (or highly similar system) where
   Ubuntu is currently installed, mostly notably so automagic hardware
   detection, and any corresponding
   installation/configuration/autoconfiguration of packages will well
   match the target hardware
o likewise save information on installed packages, e.g.:
   $ dpkg --get-selections > Xubuntu_dpkg_--get-selections
o It may be advisable/handy/useful, to also (if feasible), save a copy
   of the whole running live Xubuntu system, or if not that, perhaps at
   least most all its configuration files (e.g. everything under /etc).
   That may come in handy later for analysis/comparison purposes.
o save the apt sources configuration information
o shutdown the Xubuntu live, and reboot the installed Ubuntu
o adjust the configured apt sources as may be necessary to match those
   for Xubuntu (presuming it still uses the same repository).  Most
   notably one may need to change CD-ROM image configuration in the apt
   sources with, (I presume for {U,Ku,Xu}buntu) apt-cdrom
o use dpkg --set-selections to select packages for install that were so
   set on Xubuntu, but not the existing Ubuntu configuration.  Use
   {U,Ku,Xu}buntu's recommended tool(s) to make those updates (I
   don't know if they specify or prefer aptitude, apt-get, synaptic, ...)
   Note that tools like awk(1), sort(1), uniq(1), comm(1), etc. may be
   highly useful here.  E.g. for the aforementioned example saved files,
   for packages marked install on Xubuntu, but not Ubuntu, to produce
   list suitable for dpkg --set-selections (here the leading "> " is PS2
   prompt):
   $ {
   > awk '{if($2=="install")print $1;}' Xubuntu_dpkg_--get-selections |
   > sort -u
   > awk '{if($2=="install")print $1; print $1;}' \
   > Ubuntu_dpkg_--get-selections
   > } | sort | uniq -u | awk '{print $0, "install";}'
   That can then be saved to another file and used for input, or piped
   directly to dpkg --set-selections, but note that for --set-selections,
   one will need to be superuser (root).
o after those packages are installed, likewise produce a list to see
   what packages we earlier noted as installed on Ubuntu but that were
   not installed on Kubuntu (I'll leave how to do that as an exercise
   for the reader).  One will generally want to remove those packages -
   exceptions being packages one either explicitly installed - or
   installed as a dependency, and that have nothing to do with Ubuntu
   vs. Xubuntu (e.g.  random unrelated utility package one installed).
   The --simulate option to aptitude, or similar "preview"
   functionality, can be useful to help ensure one doesn't accidentally
   remove a dependent package, and its reverse dependencies, when such
   was not intended.  apt-cache search rdepends might also be useful to
   aid in determining such dependencies and avoiding inadvertent
   removals.  It may be advisable to also "purge", rather than remove,
   when removing packages - though one could also, and perhaps a bit
   more safely/convenient, remove first, and later purge those packages
   that have been removed (key difference being purge gets rid of
   associated configuration files, whereas remove does not).
o configuration files - the preceding should mostly cover the
   "conversion" and packages and such.  However some configuration files
   may need to be suitably adjusted.  That's where saving such from the
   live Xubuntu, as noted earlier, may come in handy.  There are also
   bits of documentation on The Internet that seem to hint at what
   file(s)[4] may need configuration tweaks.
o There are various documents/writeups on The Internet that seem to
   imply doing the Ubuntu --> Xubuntu conversion is quite doable, though
   potentially a bit hazardous.  One thing I note on most of the
   documents I easily found, is they seem to all give quite static lists
   of packages to add, and remove, to do the conversion - so those may
   only fit a very specific release version, or limited range of
   versions.  The procedure I gave should be more generic in that
   regard, by specifically getting the lists of packages, and suitably
   comparing to determine what's needed, and what should be removed (one
   could also do a list from corresponding live Ubuntu, as that would
   avoid the complication of having additional packages one has already
   installed on one's existing Ubuntu installation).  The documents I
   encountered also failed to mention updating the CD-ROM (or DVD)
   source(s) in the apt configuration.
o Anyway, once that's all done, reboot to ensure things still look good,
   and that should be it.
o Other random bits/caveats:
   o hopefully it's fairly obvious ;-), but don't be running under a
     desktop/GUI environment that uses or depends upon package(s) one is
     in process of removing whilst removing or attempting to remove them.
   o I am *not* an {U,Ku,Xu}buntu expert, these are "just" my educated
     guestimates.
   o I've not tested the proposed procedure.
   o Still, the proposed procedure may be (much) less painful than the
     safer do fresh install, then (carefully) merge data in after that.
     Besides, you do have good backups, right?  And you have tested them
     and your restore procedure (at least enough to be satisfied on
     statistic probability of successful restore/recovery)?
   o knowing how to do things from the command line is good, particularly
     if the desktop environment has non-trivial probability of breaking
     at some point along the way of the conversion procedure.

footnotes/references:
0. BUUG meeting conversation 2012-12-20
1. http://buug.org/pipermail/buug/2012-December/003961.html
2. Kubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
3. script(1):
    Script started on Sat 22 Dec 2012 06:34:54 AM UTC
    To run a command as administrator (user "root"), use "sudo <command>".
    See "man sudo_root" for details.

    ubuntu at ubuntu:~$ PS1='$ '; set -o vi
    $ unalias alert egrep fgrep grep l la ll ls
    $ cd /etc/apt
    $ ls -ond *sources*
    -rw-r--r-- 1 0 1996 2012-12-22 06:28 sources.list
    -rw-r--r-- 1 0 1898 2010-10-07 16:47 sources.list~
    drwxr-xr-x 2 0    3 2010-10-05 14:09 sources.list.d
    $ find sources.list sources.list.d -follow -type f -print
    sources.list
    $ grep '^[      ]*[^    #]' sources.list
    deb cdrom:[Kubuntu 10.10 _Maverick Meerkat_ - Release i386  
(20101007)]/ maverick main restricted
    deb http://archive.ubuntu.com/ubuntu maverick main restricted
    deb-src http://archive.ubuntu.com/ubuntu maverick main restricted
    deb http://security.ubuntu.com/ubuntu maverick-security main restricted
    deb-src http://security.ubuntu.com/ubuntu maverick-security main restricted
    deb http://archive.ubuntu.com/ubuntu maverick-updates main restricted
    deb-src http://archive.ubuntu.com/ubuntu maverick-updates main restricted
    $ exit
    exit

    Script done on Sat 22 Dec 2012 06:37:58 AM UTC
4. https://sites.google.com/site/easylinuxtipsproject/alternative