Stephan Seitz <stse+deb...@fsing.rootsland.net> writes: > On Thu, Nov 20, 2014 at 09:16:46PM +0000, Philip Hands wrote: >>Would it perhaps make sense to have etckeeper additionally keep track of >>files in /lib directories for packages that have this /etc overrides >>/lib scheme? Such packages could add their config-outside-etc > > I don’t think so, especially since those kind of files are scattered over > the fs (other files are in /usr/share). > > We can discuss what those files should be: > > - configuration files that were not put in /etc because of shortcomings > in the rpm conffile handling > - „outsourced” defaults of the application > > In the first case the files should be moved backed to /etc. In the second > case changed defaults should be documented in the changelog or readme.
Moving the ones that really are config files back to /etc would certainly be my preference, but that's not what seems to be happening currently. I noticed this when trying to diagnose what turned out to be a stick lid switch on a laptop that I'd just upgraded to jessie, and had allowed systemd to become the init. In the mean time, I've de-installed gdm3 because gnome was unusable on the old hardware, so cannot provide an appropriately detailed bug report, but I notice that the same seems to hold for other things too, so I imagine that it's a bug (or feature) of systemd or policy rather than being package specific. Anyway, the laptop was suspending every 30 seconds, and I wanted to eliminate the possibility that it was gnome that was causing it, so wanted to prevent gdm starting at boot. I imagine there's a proper way to make this happen, but my flailing attempts to do so mostly failed, in part because of symlinks that strike me as wrong -- perhaps someone can explain why things are setup like this. So, I've been vaguely paying attention. I've heard of systemctl, I know there's this etc-overrides-lib thing going on, and I know that there are things called .service files. A quick glance at the manual leads me to try: systemctl disable gdm3 (and ... gdm, and a few other things) -- none of which work. So, then I try editing /etc/systemd/system/gdm3.service to tell it not to go, which means that I start seeing syntax errors (not really reading manuals much here -- I'm doing this in 30 second chunks remember ;-) ) So instead I remove the file and create an empty file. No effect. Later I realise that this is because there are more than one symlink From etc to lib for this file, and it's cross-linked inside lib as well, and my first edit was not on a file under /etc, but actually the one that's pointed at under /lib. In the end, replacing all the symlinks (including one called something verbose like desktop-environment) with empty files stopped gdm from being started, and then soon after I realised what the real problem was (the lid switch) and all was well. It seems quite dangerous to me to have these symlinks pointing out of /etc, just waiting for unsuspecting sysadmins to start editing files that are going to be quietly overwritten when the next upgrade happens. Given the fact that it's supposed to be etc overrides-lib I don't really see why they're there. Perhaps someone can explain the thinking behind this. If not, perhaps we need some policy to stop more of this sort of thing (looking in /etc/systemd on this machine I see that I have similar symlinks for rsyslog and ssh and probably others). I know this should perhaps be a bug report, but the laptop in question is to old to get anything good to happen with Gnome (particularly since the 3d effects provoke the glyphs to rot and be replaced by noise) so it's running LXDE now, so gdm3 would need to be re-installed before I could start with that, and when I did start looking into it again, I notice that ssh is doing the same thing anyway by the looks of it, so it's a more generic issue anyway, and perhaps not a bug at all -- hence this mail. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
pgpyGrXZbynIl.pgp
Description: PGP signature
