https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #17 from koenig@linux.de 2006-11-27 11:03 MST ------- for a suggestion how to migrate from legacy dirs to symlinks, see below for my RFC... (In reply to comment #16)
Well, we cannot create symlinks for each possible X.Org Xclient in /usr/bin. If we do this we'll never get rid of /usr/X11R6/bin and can never replace it with a symlink to /usr/bin.
strange argumentation. so let's break existing systems, which use paths which have been stable for 10+ years without any prior warning? it's a matter of the correct sequence and communication. _first_ provide the new solution plus full backward compatibility _and_ explain yout future change path. _later_ (1, better 3 years from now) cut off the legacy stuff.
See above. /usr/bin/X11 symlink to /usr/bin is in place with RC2.
good. but most Linux apps/scripts nowadays will (unfortuneately) /usr/X11R6/bin/ instead of /usr/bin/X11/
We already have some symlinks, e.g. xauth. Work on providing a script for more (which one exactly?) is simply to late IMHO. In the worst case
cd /usr/X11R6/bin; ln -s /usr/bin/* .
will still work for the customer (brute force).
that's a really ugly last resort. please do so really if nothing else is possible. problem with that workaround: _when_ do you create these links. it's not enough to run that "ln -s /usr/bin/* /usr/X11R6/bin/" just once at update/installation time. think about the following use case: system is installed or upgraded (doesn't matter), but doesn't have "Xnest" installed yet. now you get some nice tool/script/... whatever which needs Xnest (or some other Xserver like Xvfb, Xprint, nxagent, ...) and the old script or tool-webpage explains in non-10.2-aware-mode: just run xinit /dir/magictool -- /usr/X11R6/bin/Xnest :1 just installing the xnest package will break that old solution ("this always worked/works fine for non-SUSE-10.2 [TM]"). so IMHO you'd have to update those tonns of legacy symlinks with every run of SuSEconfig. uuuuugly.
Probably you mean /usr/X11 --> /usr/X11R6. Honestly, it's no longer available. Nobody noticed/missed it up to now. Since nobody missed it, it won't hurt to add this symlink.
so you state that there will be no other 10.2 customers other than OSS beta testers ? can't be true, is it!? hopefully not;-) I myself don't know much tools which use /usr/X11/... instead of /usr/X11R6/... but I would never dare to state "nobody used that and will notice it's missing". you _will_ hurt someone without prior warning, and that's not nice. now to my RFC: I think we need symlinks to directories for the best and easiest compatiblity layer. one advantage (amnoung many others) would be that you only have one legacy link to be removed per directory -- think about the later cleanup of a /usr/X11R6/bin/ with zillions of symlinks to /usr/bin/ plus lots of legacy apps which still exist in (or newly have been installed to) /usr/X11R6/bin/. if you want to get rid of /usr/X11R6/bin/ and similar dirs, do it *now* (and keep them as symlinks for some time). for example we need /usr/X11R6/bin -> /usr/bin or better (let's discuss about absolute/relative symlinks in another thread -- here I only care that there will be symlinks at all;-) /usr/X11R6/bin -> ../bin this is just one example, there will be other directories which will have be handled the same way. now, NOW shall we achive this for 10.2 ? a) new installation: should be no problem here: just add those symlinks plus empty destination directories in filesystem.rpm. it will get installed at the very start, so even you own "legacy style apps" in 10.2 like susevbox alsamixergui bbtools cjk-lyx gvim pacman rfb transset xcdroast xmgrace (have a look at the output of "pin /usr/X11R6/bin/" for details, will be installed at the "correct" new path. otherwise it's hard to approach your goal to avoid "we'll never get rid of /usr/X11R6/bin" even with plain 10.2++. b) so the hard thing is the system upgrade from post-10.2 to 10.2. the following code should go into the pre-install script for filesystem.rpm to rearrange things before the new symlinks will be created -- completely untested so far, so all typos are mine[TM] : srcdir=/usr/X11R6/bin destdir=/usr/bin mkdir -p $destdir # just in case... # try to move stuff to new dir, but do not overwrite existing stuff # maybe better use xargs or "for" loop just in case there are too many entries cd $srcdir || exit # or "break" loop or whatever yes no | mv -i * .* $destdir/. 2> /dev/null # don't forget .* files !! cd $srcdir/.. # or cd $destdir or cd / if ! rmdir $srcdir ; then # directory not yet empty :-( mv -f $srcdir $srcdir.rpmold echo we moved your legacy directory $srcdir -- please check contents and move it to $destdir | Mail -s "update notice" root fi ln -s $destdir $srcdir # not really neccesary, sym link should be part of filesystem.rpm and run this for some pairs of srcdir/destdir (like bin, fonts, app-defaults, whatever). I thought about this for a while and I still think it - is doable - has no higher risk than breaking lots of legacy scripts - is the right way to go *now*. but obviously noone can think about all circumstances, that's why I ask for comments (RFC) on this method! thanks for any input -- and thanks for any symlinks and compatibility help/link/layer in the upcoming 10.2, whatever solution you'll finally squeeze into the RC2+ !!! Harald -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.