On Wed, May 17, 2006 at 07:30:51PM +0200, Johannes Wiedersich wrote:
> Digby Tarvin wrote:
> >There should be no problem sharing /home provided you are careful about
> >a few minor things - principally:
>
> Well, and you should be sure that all your distributions always have the
> same versions of some of the programs you use. It's not always obvious,
> that different versions of the same program use the same or at least
> compatible configuration files.
IMO that indicates an application flaw which is not just a problem when
dual/multi-booting. It is also an issue when you want to retain multiple
versions of an application on one system.
> So I would recommend to use different home-directories for both
> distributions. You could move your data all in one subdirectory of /home
> and make that accessible to your user from the other OS via using the
> same user name/user id and/or group and placing a link in that other
> home directory. Eg.
> ln -s /other/home/data /home/data
>
> If you happen to have specific configuration files that you want to
> share between distributions you could also just link their names from
> one home directoy to the other.
I did try that when I was running gentoo and SuSE side by side - mainly
becuase it was only a temporary configuration while I decided which to
run with...
It works, but I found it a little clumsy to have to remember to keep
dropping that extra directory.
In general, as I have said before, the 'hidden files in your home directory'
approach to user customization in unix has outlived its usefulness ever
since the number of files grew past about three.
Off the top of my head, one not so hard way to fix things would be to
put all of your configuration files in dedicated directory, the name
of which is configurable. All applications use $CONFIGDIR/.whatever
instead of $HOME/.whatever, and each OS you install simply gets
assigned a different $CONFIGDIR, such as for example
CONFIGDIR=$HOME/config_etch
The problem is that this is a very small change to a very large number
of applications, which is tedious to do as an individual.
You can achieve something similar without having to change applications
if you use a little cunning. For example, I am running 8 different
versions of netscape on this system (long story), but they can't
share a common $HOME/.netscape directory and there was no way to
specify an alternative.
The solution was to invoke the different versions with a modified
environment which changed HOME to HOME/.version. For example,
in $HOME/bin I have a netscape4.73 script containing:
#!/bin/sh
#
# Kludge to allow multiple versions of netscape to co-exist
# by executing it with an update PATH and HOME
#
VERSION=`basename $0`
MOZILLA_HOME=/usr/local/$VERSION
PATH=$MOZILLA_HOME:/usr/bin:/bin:/usr/contrib/bin:/usr/local/bin
export PATH
HOME=~/.$VERSION
export HOME
exec /usr/local/$VERSION/netscape $*
Result was that I could run any combination of versions side by side when
doing compatability testing...
That doesn't work so well for things like shells and display managers
which are executed on your behalf as you log in (so you can't put them
in a wrapper). But there are far fewer of those, so it is usually
feasible to implement a better fix, such as reconfiguring to use
versioned configuration directory names...
A simple way of doing that is to tell each system that your home directory
is actually /home/$USER/$SYSTEM, so that each application gets its config files
from this directory, but the root of your personal file tree is $HOME/..
A minor modification to 'adduser', and a 'cd ..' at the end of your
login script, and you have something pretty close to a clean system that
keeps config files in per-system sub-directories and your personal files
are not spread across multiple filesystems.
It does, of course, depend on your objective. If your mix is temporary,
or one of the two installations is a 'primary' and the other is just
experimental, then keeping separate /home directories with a shared
sub-directory is probably the easiest solution (doesn't have to be
two separate partitions though).
If it is a long term setup then I tend to customize my config files
and devise suitable workarounds for errant applications that for
some reason have conflicts between versions.
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
