In the past, I've gone hog wild customizing my Ubuntu installation, only to be unable to upgrade it once the time came. So how does one go about customizing their install without running into issues upgrading? Is it possible to do so without relying solely on the Ubuntu repositories for software?
-
2Can you tell us why you were unable to upgrade?– Nathan OsmanJul 29, 2010 at 5:51
-
@georgeedison Unfortunately, I don't recall. It was about two years ago, going from one of the 8.x to a 9.x release. I had installed a bunch of things from source and third party repositories. Since then, I've avoided installing anything that isn't in the Ubuntu repositories, but I'd rather know how to approach this without being limited to those repositories.– George MarianJul 29, 2010 at 6:26
1 Answer
One important factor in making upgrades run smooth is not to do anything which confuses the package manager. That is, you shouldn't yourself touch areas of the system which the package manager expect to be its domain. A few concrete examples.
If you compile/install programs yourself using the ./configure; make; make install method, don't put them directly under /usr
. It is better to use /usr/local
or /opt
, alternatively (even better) to roll your own deb packages.
When you remove packages you can either do a normal removal or an explicit purge. Unless you purge the package the package manager might leave files behind under /etc
, /var
and so on. Do not delete these files yourself, as the package manager expects them to be there. Instead use your package manager to explicitly purge the remains of the package.
Using deb package from third party repositories should theoretically be safe, assuming they are carefully built etc. Yet, to be on the safe side you might want to consider removing those packages and/or repositories before you perform an upgrade to a new Ubuntu release.
Ok, let me see if I can add some more meat to this answer...
First of all, everything you do in your home directory is perfectly safe in regards to the package manager. It will never touch anything under /home
.
(Of course, you can still cause yourself plenty of confusion by doing bad thing to your home directory. Luckily that is usually be recovered from by removing the broken configuration files from your home directory, and let them be re-created from default at the next use. Do note that the automatic re-creation of default config only goes for your personal configuration files, not the system wide stuff under /etc
)
In the role of a (power) desktop user I guess the most common system wide creativity will be installing extra applications, libraries, emacs modes, etc? Again, the really important part is to always put none deb package stuff under /usr/local
instead of under /usr
; to use /usr/local/bin
instead of /usr/bin
, to use /usr/local/share/emacs/23.1
instead of /usr/share/emacs/23.1
and so on.
Once you start playing around with server daemons you will soon be confronted by the system wide configuration under /etc
. While you generally can modify files under /etc
, you should "never" actually remove a file or a directory there, unless it was you who created it yourself. Likewise should you be careful about yourself creating new files in there, in case they would later on collide with a configuration file the package manager want to create. That being said, there are definitely files which you can (and should) be created under /etc
. On of the more common examples is defining your Apache VirtualHosts under /etc/apache2/sites-available
.
There might be times when you want create files or directories under /var
. While it is a completely different place than /etc
, still consider the same rules about being careful and doing things on individual consideration.
In case you want to know more, it won't hurt you to take a peek at the Filesystem Hierarchy Standard (FHS) or in the Debian Policy Manual. While it might be completely overkill in answering your original question, it is still a good read.
-
That is, you shouldn't yourself touch areas of the system which the package manager expect to be its domain.
Beyond your examples, how can I determine which areas these are? Jul 29, 2010 at 6:29 -
-
Primarily as a desktop, though I'm a developer. So, I would be interested in knowing what issues are faced in both environments. If you have to pick one over the other (e.g. to keep things relatively short), I'd say desktop. Jul 29, 2010 at 7:01
-
1If I am not installing something from source system-wide, I generally create a ~/local/ directory and put those things there. Generally, if stuff hasn't radically changed during an upgrade, all of that stuff will still work without further intervention from me.– JimJul 29, 2010 at 13:33
-
This is especially tedious for developers, who need versions of libraries not yet packaged. Great care should be taken to install these things in /usr/local and adjust linking accordingly / etc.– Tim PostJul 29, 2010 at 15:33