Hi.
Starting point
==============
Last night fun were expected with a test of the new zim-0.63.
Previous version were installed via deb package, zim-0.62.
For some reason I usually still work with zim-0.60 via symlinks to
a separate extracted tar zim-0.60 archive. This should be kept.
Symlinks
========
There was the idea to use symlinks in /usr/bin for zim,
created as a temporary hack some way. Don't take it literally,
don't remember the exact situation today.
# ---
cd /usr/bin
ln -s /root/zim/zim-0.62/zim.py zim-0.62
ln -s /root/zim/zim-0.63/zim.py zim-0.63
ln -s zim-0.63 zim
# ---
One and maybe very few other symlinks should point to the wanted zim version
commonly used by quite a couple of accounts.
Why symlinks are bad
====================
Then I realized that zim looks for templates and other stuff at several
directories if existent, think of $PATH and position dependent dir entries.
The first wins.
One unwanted winner example was /usr/share/zim tree, which existed
only once for zim-0.62 at that time. Mixing up several zim versions
is a bad idea, because the pure zim-0.63 features should be tested.
# Remark: There is no compatibility problem with respect to zim books.
Uninstall zim-0.62
==================
The next idea was to just uninstall zim-0.62 via Ubuntu package management
and nevertheless go on with existing extracted tarballs. Removed things
cannot be found after all, which is good. Let zim search harder to find
its stuff at extracted tarball and see what happens.
Lost /usr/bin/*
===============
But now suddenly nothing worked the way it should any more.
No ssh, no du and most applications could not be started any more.
Booted from a rescue stick and verified that disk is ok with fsck.
# -----------------------------------------------------------
# ----- > It turned out that /usr/bin was just empty. < -----
# -----------------------------------------------------------
The only reason I can imagine is that some uninstall procedure of a zim debian
package removed its stuff for uninstall using wildcards, assuming that zim is
unique enough to not clash with other files or dirs.
Guess, restauration of /usr/bin/* took a while.
Lesson learned
==============
Never mix up manual adjustments with automated package management tools.
Otherwise be prepared for ugly events.
This short story is just for sharing experience.
Have a nice day ...
Andreas
_______________________________________________
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help : https://help.launchpad.net/ListHelp
