This request is superseded by
request 839544
(Show diff)
Overview
Request 839395 superseded
Properly track compat symlinks
- Created by Vogtinator
- In state superseded
- 4 package maintainers
- Superseded by 839544
Loading...
openSUSE Build Service is sponsored by
Hmm. Unfortunately this doesn't consider /etc/X11/xinit/xinitrc.common at all. I doubt we'll ever get rid of this compatibily link. We cannot patch files in user's $HOME.
Also I don't see how I could get rid of xdm-config and Xservers, which is patched depending on values in /etc/sysconfig/displaymanager. This config file is a different story. I would like to keep this separate!
I still need to find out who/when Keyboard.map is being used. It could be during build process to generate Linux console keymaps. In that case packaging would even be good!
In short. For now I'm fine with packaging Xsession Xsetup Xstartup Xreset Keyboard.map. The remaining symlinks I still want to create on the fly.
This sr has two packages, xinitrc.common is part of xinit.
I see, but previously those were normal files and tracked by xdm, so I wonder how that worked.
No idea, there are no hits in /usr or /etc. systemd uses its own /usr/share/systemd/kbd-model-map and YaST has its own stuff on top. So it might even be ok to just drop it?
Ok, I'll supersede.
I just checked, SUSEConfig is dead and nothing appears to write into those files anymore.
And I also found where Keyboard.map was used, but not anymore:
https://github.com/yast/yast-x11/commit/baa8e08b00849e74178f051b162a224b9bc985d4#diff-e9c878ace42e215f62349413d22bf3df
I just checked, SUSEConfig is dead and nothing appears to write into those files anymore.
/etc/X11/xdm/SuSEconfig.xdm is called by /usr/lib/X11/display-manager, bah.
Yeah. it's still in use. ;-)
Keyboard.map: Ah. I read it wrongly. It converted in the different direction and has been replaced meanwhile. I can remove it completely.
Ah. You moved /etc/X11/xinit/xinitrc.common to a xinit package. As said, we'll never get rid of it in a working system. I still prefer having it created on-the-fly if the admin removed everything below /etc.
Recreating it on-the-fly is fine, but it has to be tracked by rpm as well.
As ghost then? But then a file below /etc will still be in the package, which is no longer allowed, right?
I don't think it'll ever be forbidden to ship files below /etc, especially not for cases like this where it's about users we don't have control over (~/.xinitrc). I would just track it as normal file, so that rpm -qV (rightfully) complains if it's missing.
Ok. Mabye you're right.