https://bugzilla.novell.com/show_bug.cgi?id=223524 andreas.hanke@gmx-topmail.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andreas.hanke@gmx-topmail.de ------- Comment #1 from andreas.hanke@gmx-topmail.de 2006-11-23 17:45 MST ------- Should have been discussed much earlier, as adding compatibility symlinks now without enough time for testing can totally break system upgrades. (Background info: rpm errors out when trying to replace a directory with a symlink or vice versa and needs workarounds + extra care.) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 sndirsch@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aj@novell.com Status|ASSIGNED |NEEDINFO Info Provider| |ro@novell.com ------- Comment #3 from sndirsch@novell.com 2006-11-23 22:49 MST ------- BTW, /usr/bin/X11 --> ../X11R6/bin has been part of xorg-x11 package in 10.1. Not sure if it's possible to replace an existing symlink with a different symlink during an (RPM) update. /usr/bin/X11 --> . Rudi, what do you think? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ro@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|ro@novell.com | ------- Comment #6 from ro@novell.com 2006-11-24 06:31 MST ------- for #3: replacing one symlink with another should be uncritical, replacing symlink with directory and vice versa usually has issues. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 sndirsch@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sndirsch@novell.com AssignedTo|sndirsch@novell.com |freitag@novell.com Status|ASSIGNED |NEW ------- Comment #8 from sndirsch@novell.com 2006-11-24 08:17 MST ------- done. Klaas, please reassign back to me after moving /usr/X11R6/include/grace_np.h to /usr/include (when 10.2 is done), so I can then remove the /usr/X11R6/include directories from filesystem package. Thanks. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #11 from sndirsch@novell.com 2006-11-24 20:42 MST ------- Thanks, Egbert. But I already wrote that I patches libXt accordingly. Check app-defaults.diff in xorg-x11-libXt package. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 eich@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ms@novell.com ------- Comment #14 from eich@novell.com 2006-11-26 23:50 MST ------- (In reply to comment #13) * Stefan, the binary issue is the most important one here. A lot of remote scripts have paths hardcoded because the X11R6/bin (or any other X11) subdirectory has not been in the search path of a remote shell on some systems. This served as a cheap way for parallel installation of X and non-X versions of the same application. * Also the xinit semantics requires the specification of full paths. Using remote scripts that start xinit directly or indirectly will only work if they are using the /usr/bin/X11 path. Scrpits that use /usr/X11R8/bin will fail. * If there is no way we can replace /usr/X11R6 we may have to populate /usr/X11R6/bin with symlinks to servers, window managers and xterm. Since it is already late in the game we may want to provide a script (that we mention in the release notes) for the administrator to run to generate the required sym-links? * What is the solution for /usr/X11? It has been a symlink to /usr/X11R6/bin and should be replaced by a symlink to /usr. * fontconfig seems to be fine. The conservative apporach to keep the old paths in the config files should help. This at least was the case on the updated system I've checked. * These however should be readded to the server font paths. The server is probably going to bitch about it in the log file (this code should probably be put on a higher verbosity level). Adding Marcus.

Egbert, I'm aware of the configure option for the libXt app-defaults, but found it much more easier to create a patch for configure.ac. :-) No, the app-default configure option is *not* what I was talking about but it was the --with-xfile-search-path. looking at the code it should even suffice to append the new path to the old. app-defaults are however the least important issue here.

-- 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.

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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #19 from andreas.hanke@gmx-topmail.de 2006-11-27 11:55 MST ------- Do you really want to add an /usr/X11 -> /usr symlink now? What will happen is exacty what happens about /boot/grub: There will be bug reports of the sense "what's the purpose of these 42 nested directories with the same content". /usr/bin/X11 -> /usr/bin is probably OK because users rarely look at /usr/bin (it's scary anyway) and /usr/bin/X11 was explicitly mentioned as a path that users can rely upon in FHS 2.3. But /usr/X11 -> /usr is something I tend to find really ugly. I'll attach a screenshot. And /usr/X11 wasn't a supported entry point in FHS 2.3, it's not mentioned a single time there. I wonder who used it and why this compatibility symlink should be needed, given that it was never FHS-blessed. FHS 2.3 says: /usr/bin/X11 is what users should use for binaries (now fixed with a symlink to /usr/bin) /usr/lib/X11 is what users should use instead of /usr/X11R6/lib/X11 (no need to fix anything here because this is now the real path) /usr/include/X11 is what users should use instead of /usr/X11R6/include/X11 (dito) http://www.pathname.com/fhs/pub/fhs-2.3.html#USRX11R6XWINDOWSYSTEMVERSION11R... There is no instance of /usr/X11 in this document. Otherwise, all tools should continue to look at the old directories (they mostly already do so), but the purpose of the move was getting rid of /usr/X11R6 which is considered legacy stuff. It's known since quite a while that Xorg >= 7.0 doesn't use this hierarchy any more, SUSE actually gave you much more time for fixing scripts than other distributions who did 6.8 -> 7.0 (SUSE did 6.8 -> 6.9 -> 7.2, 6.9 is the same as 7.0 with X11R6 paths and a different build system). -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #21 from sndirsch@novell.com 2006-11-27 12:39 MST ------- I'm talking about the /usr/X11 --> /usr/X11R6 symlink. -- 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.

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. No I was taling about linking /usr/X11 to /usr. This makes more sense than

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #23 from eich@novell.com 2006-11-28 03:10 MST ------- Too many and too verbose comments in here. trying to link it to the already defunct /usr/X11R6. Circular paths may be bad - but the only way to get around certin issues. We may also create /usr/X11 as a directory now and create a link from/usr/X11/bin to /usr/bin (and probably from all the subdirectories in the old /usr/X11 to their respecitve counterparts in /usr) but this may be even harder to get rid of.

...

* These however should be readded to the server font paths. The server is probably going to bitch about it in the log file (this code should probably be put on a higher verbosity level). Adding Marcus. Hmm. Only when we put the code on a higher verbose level. Customers are often complaining about invalid font directories. :-( I seem to be really unclear. Verbose level in X work like this: the default verbose level is 3. Any message that gets printed with a level higher than 3 isn't shown unless the user increases the verbose level of the server. Therefore if we hack the code and increase the level for the message complaining about an invalid font path the user wont notice it unless he turns on a higher verbostiy level for debugging. Another solution may be to word the message differently.

Frankly I don't know how to fix Harald's concern about /usr/X11R6. There doesn't seem to be a good solution - and non that would work for the release. I like his idea for new installation. However we cannot get this into this release any more - and obviously it's nothing that can be fixed with online updates. I'm relucatant about the other ideas about updates right now. They'd require some more testing. I will comment on them later. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #25 from koenig@linux.de 2006-11-28 05:15 MST ------- (In reply to comment #18)

BTW, the switch from X.Org 6 to X.Org 7 (/usr/X11R6 --> /usr) has been discussed on opensuse about 5 months ago. It's unfortunate that you didn't join the discussion and began beta testing (as usual) with RC1. :-(

yea, really pitty :-( my first beta-test was beta-2 (the real world/life...) and I only needed Xnest in RC1 for some tests -- and realized that this got severly broken... anyway, do you have a pointer (URL) to this/those mail threads ? I really wonder, if noone else cares about upward compatibility and breaking existing stuff, or (if there have been those concerns earlier) why there exists no miration plan from old to new paths. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #27 from sndirsch@novell.com 2006-11-28 05:31 MST ------- Pointer for the mail thread. http://lists.opensuse.org/ Search for X.Org 7 or similar. I no longer remember which ML this was, probably opensuse-factory. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #29 from eich@novell.com 2006-11-28 10:00 MST ------- (In reply to comment #24)

...

We may also create /usr/X11 as a directory now and create a link from /usr/X11/bin to /usr/bin (and probably from all the subdirectories in the old /usr/X11 to their respecitve counterparts in /usr) but this may be even harder to get rid of. Hmm. As already said replacing symlinks with directories is also critical, so it's nothing we should do now:-(

Right, therefore I'm all for /usr/X11 -> /usr.

I understand the verbose level concept. Either we could use another verbose level as default or set the messages about invalid font paths to a higher one. Anyway I don't think it's such a big issue, since we moved all fonts from our distributions to /usr/share/fonts and there are not that many external fonts in use I think (MS webfonts/Acrobat reader fonts come to my mind).

We don't. But ISV software (3rd party) might. It is conceivable that ISVs don't change things in there software to match the new behavior right away. What does the filesystem standard have to say about this anyway?

I need to have a closer look at Harald's proposals - after 10.2.

-- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #31 from eich@novell.com 2006-11-28 11:27 MST ------- (In reply to comment #28)

in theory it should be possible to run my RFC script stuff at any time, isn't it ? obviously I've not tried running it myself yet ;-)

Yes, it should run at any time.

I could think of a new, independant RPM (which might be available as post-10.2 online-update) called "give-me-legacy-X11-paths-compatibility.rpm" which does exactly that directory moving and symlink creation stuff. users would be free to install it or not. right now I don't see any specific problem doing this stuff at any time as it doesn't break any existing new paths but only adds additional (formerly broken) old access paths. am I wrong ?!

Can we forsee that this will not break a later update under all circumstances?

right now I think I'll create such an legacy-update script for myself and our company before I move any non-testing system to 10.2-final. if this will happen I'll let you know and report about my experiances (so stay tuned... ;-)

If we ship this it may create a support issue in the future. If for instance you cannot remove the directory because it's not empty there may be a binary with the same name in the other directory. In this case if you move the directory and link you may create a validation error or an uninstall may later catch the wrong file. If such duplicates exist (and I think in the past they did to destinguish between X and non-X aware versions of an application) it may not be save to monkey with the directory at all - without risking the integrity of the installation. That's why I don't like to ship such a script. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #33 from sndirsch@novell.com 2006-11-28 13:14 MST ------- I don't have access to Fedora, Mandriva or to any other Linux distribution, which already ships X11R7. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #36 from koenig@linux.de 2006-11-29 11:27 MST ------- (In reply to comment #31)

Can we forsee that this will not break a later update under all circumstances?

thinking a bit harder I always can imagine some brain dead mechanisms in the next update which will break with whatever you ask me to break ;-) what I can forsee for sure: there are a some issues being mentioned here which _will_ break without such compatibility adds. and breaking stuff in 10.2 and only offering a fix in 10.3 _many_ months later for sure will make more than annoy some SUSE admins/users.

If we ship this it may create a support issue in the future.

if you don't ship this you'll have some update support issues in the near future. ok, your support crew will just answer "hey, the broken script is yours and not ours, so just go away and fix it yourself" but the reputation of SUSE/Novell won't increase with such behaviour...

If for instance you cannot remove the directory because it's not empty there may be a binary with the same name in the other directory. In this case if you move the directory and link you may create a validation error or an uninstall may later catch the wrong file. If such duplicates exist (and I think in the past they did to destinguish between X and non-X aware versions of an application) it may not be save to monkey with the directory at all - without risking the integrity of the installation. That's why I don't like to ship such a script.

vaild point. two thoughts (no solution:) about this: - the admin must be told (via email, popup window, ...) about these duplicate images & directory renaming. so (s)he knows and shall resolve that confilcts _before_ the next update (say 10.3 or whatever) is scheduled. if not -- at least he has been warned before and had quiet some time before the emergency case happens. right now the desaster will happen without any notification... - never do any admin work (esp. updates) without proper/decent/checked backup [tm] ;-) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 ------- Comment #38 from eich@novell.com 2007-01-15 04:21 MST ------- One viction of this change is Emacs. See bug #234026. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=223524 sndirsch@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Comment #40 from sndirsch@novell.com 2007-01-30 13:28 MST ------- *** This bug has been marked as a duplicate of bug 239089 *** -- 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.