MIA: /etc/lightdm/lightdm.conf.bunsen-orig

Head_on_a_Stick · 2016-12-21 21:19:35

^ +1

I think the final option is the most consistent with our general approach (if that make sense).

martix · 2016-12-21 22:08:22

Is that all? Just replacing ".dpkg-new" by "-orig" for those two files? I did that already, works fine here.

johnraff · 2016-12-22 02:47:01

damo wrote:

Are there any problems for the user if the files have been named incorrectly...?

Potentially, yes.

Right now those dpkg-new files are just backups, but if bunsen-configs is ever uninstalled they will be (or should have been) used to restore the original default lightdm.conf files. Because lightdm.conf.bunsen-orig doesn't exist, no lightdm.conf will be created.

If the user chooses Menu>System>Login Settings the text editor will open a blank file. In fact, that means the default settings will be applied, so the main problem for the user will be not having all those commented-out entries as a guide. (I think any new entries they add to an empty lightdm.conf will still work as long as all the syntax is right.)
The same applies for the lightdm-gtk-greeter files.

Why this has just come up is that, in applying xaos52's suggested improvement to bunsen-configs, the displacement of lightdm.conf will indeed be removed (the BL custom config will be done in /usr/share/lightdm/lightdm.conf.d instead), giving rise to the above issue.

@martix the renaming should be from *.dpkg-new to *.bunsen-orig and, as you noticed, it makes no difference to a standard BL setup at the moment. (It might be safer to copy the files, rather than rename; the old .dpkg-new files will do no harm.)

---

I've just tested again on a VM, and making a copy of *.dpkg-new as *.bunsen-orig does fix the issue when the diversion is removed. I'm starting to lean towards adding that hack to the preinst file of the new bunsen-configs so that the new setup will go in cleanly. Users won't have to do anything.
@damo and @HoaS I appreciate the philosopy there, but in this case we're just cleaning up our own mess. Most users wouldn't learn anything particulary useful from having to dive deep into the quirks of (a possibly old version of) dpkg, would they?

Last edited by johnraff (2016-12-22 02:53:09)

Head_on_a_Stick · 2016-12-22 07:14:49

johnraff wrote:

I'm starting to lean towards adding that hack to the preinst file of the new bunsen-configs so that the new setup will go in cleanly. Users won't have to do anything.
@damo and @HoaS I appreciate the philosopy there, but in this case we're just cleaning up our own mess. Most users wouldn't learn anything particulary useful from having to dive deep into the quirks of (a possibly old version of) dpkg, would they?

Yes, good point, I agree with that plan.

martix · 2016-12-22 13:51:19

@johnraff Oh, forgot ".bunsen", so it's to ".bunsen-orig". Thank you for the correction.

johnraff · 2017-01-09 04:02:26

OK the fix is finally pushed to bunsen-configs deuterium so as soon as that version is released, and people upgrade, their /etc/lightdm directories should be OK. (There will be some unused file copies hanging around, which I didn't remove, just to be on the safe side.)

I've also written a hook which will fix the next iso release.

It does seem to be a strange dpkg bug, and it would be nice to stop it happening in the first place, but I'll leave that for later...

#21 2016-12-21 21:19:35

Re: MIA: /etc/lightdm/lightdm.conf.bunsen-orig

#22 2016-12-21 22:08:22

Re: MIA: /etc/lightdm/lightdm.conf.bunsen-orig

#23 2016-12-22 02:47:01

Re: MIA: /etc/lightdm/lightdm.conf.bunsen-orig

#24 2016-12-22 07:14:49

Re: MIA: /etc/lightdm/lightdm.conf.bunsen-orig

#25 2016-12-22 13:51:19

Re: MIA: /etc/lightdm/lightdm.conf.bunsen-orig

#26 2017-01-09 04:02:26

Re: MIA: /etc/lightdm/lightdm.conf.bunsen-orig

Board footer