Add Debian alternative for login background?

johnraff · 2016-03-06 03:43:08

Wallpapers are set on a per-user basis so changing them is easy. The login background, though, is a system file. Since BL diverts /etc/lightdm/lightdm-gtk-greeter.conf to /etc/lightdm/lightdm-gtk-greeter.conf.bunsen, which has a hard-coded call to /usr/share/backgrounds/bunsen/bunsen-images/bl-default/bl-login-1920x1200.png, a user edit to that file will probably be overwritten by an upgrade to bunsen-configs, making it hard for sysadmins to change the login background.

In this post I suggested using Debian alternatives to set the login background. Since we're already doing the same with desktop-grub it would be fairly easy to implement.

We could either
1) use one of the existing alternatives desktop-background (intended for wallpapers) or desktop-splash (intended for the splash screen)
or
2) invent a new alternative bl-login-background (by analogy with bl-file-manager etc) and use that.

Opinions?

Horizon_Brave · 2016-03-06 05:17:11

John, is it vital for BL to divert the file to /etc/lightdm/lightdm-gtk-greeter.conf.bunsen ? Wouldn't removing the diversion fix the issue as well?

Also, does it have to be a file in the debianAlternatives or couldn't it be any arbitrary file

johnraff · 2016-03-06 06:28:13

The diversion of /etc/lightdm/lightdm-gtk-greeter.conf is necessary to put in our custom configurations for LightDM.

Using a Debian Alternative for the login background would make it very easy for the user to modify.

Last edited by johnraff (2016-03-06 06:29:22)

Head_on_a_Stick · 2016-03-06 09:58:11

I like the second option best.

Changing the LightDM set up is a problem in vanilla Debian too:
http://forums.debian.net/viewtopic.php?f=6&t=122506

Horizon_Brave · 2016-03-06 15:06:55

Ah I see, so basically we'd create something like /etc/alternatives/login-background-image specify a default B.L wallpaper there. Then you'd change /etc/lightdm/lightdm-gtk-greeter.conf.bunsen to point to the newly made login-background-image that we set up?

Therefore if a user changes the login-background-image from our default, and then updates lightdm, it's own update is agnostic to our 'inner' wallpaper config?

pvsage · 2016-03-06 18:10:14

I suppose my predictable response is predictable. +1 to creating a new bl-login-background Debian alternative.

For what it's worth, I think the reason the default config for LightDM in Debian uses desktop-background is to give a more unified look from login to desktop on a vanilla Debian installation.

Horizon_Brave · 2016-03-07 02:11:43

Wait, doesn't this also mean that any customizations in the /etc/lightdm/lightdm-gtk-greeter.conf file will be overriden back to defaults? There's other parameters in there, not just wallpapers, like clock-format, fonts etc.. so if the whole file is being overridden on an update, these changes would all be lost as well, not just the wallpaper right?

johnraff · 2016-03-07 06:22:08

pvsage wrote:

For what it's worth, I think the reason the default config for LightDM in Debian uses used desktop-background is was to give a more unified look from login to desktop on a vanilla Debian installation.

FIFY
LightDM's default config file now points to '/usr/share/images/desktop-base/login-background.svg'.

@Horizon_Brave It's OK. bunsen-configs uses a form of dpkg-divert to install lightdm-gtk-greeter.conf.bunsen and /etc/lightdm/lightdm-gtk-greeter.conf is just a symlink pointing to that. Our customizations are proof against upgrades to LightDM. The issue here is that user's customizations wouldn't be proof against upgrades to bunsen-configs without this Debian Alternatives abstraction.

So, go with the bl-login-background alternative, I guess.
Best place to install the symlink (not the image files themselves)?
/usr/share/bunsen/bunsen-images/alternatives/?
/usr/share/images/bunsen-images/?
/usr/share/backgrounds/bunsen/bunsen-images/alternatives/?
other??

bl-* applications are in /usr/bin/
desktop-* are in /usr/share/images/desktop-base/

pvsage · 2016-03-07 08:18:21

johnraff wrote:

pvsage wrote:
For what it's worth, I think the reason the default config for LightDM in Debian uses used desktop-background is was to give a more unified look from login to desktop on a vanilla Debian installation.
FIFY
LightDM's default config file now points to '/usr/share/images/desktop-base/login-background.svg'.

Huh; would you look at that. Somebody needs to update the Debian wiki.

OK, so if vanilla Debian doesn't have the desktop-background alias anymore, I guess that means BunsenLabs doesn't need an equivalent.

johnraff · 2016-03-07 10:07:45

^They still have the desktop-background Debian alternative (for wallpapers I guess), but LightDM doesn't use it any more.

Horizon_Brave · 2016-03-07 15:52:58

Wouldn't it be wise to create a usr/share/bunsen/alternatives directory for all and future alternatives we create later on? Instead of one specifically in the images or backgrounds directory? Just to keep future alternatives all in one place...

Also, as a side question, if the creation of alternatives is used to solve this, would the user then need to set his wallpapers with the update-alternatives command each time?

Last edited by Horizon_Brave (2016-03-07 21:05:16)

spacex · 2016-03-08 00:19:17

johnraff wrote:

The diversion of /etc/lightdm/lightdm-gtk-greeter.conf is necessary to put in our custom configurations for LightDM.

I'm sorry, but I don't understand why. I'm able to put in my custom LightdDM configuration in live-build, without doing that. It's just to include the configs in the live-build, and add this to preseed.cfg,

ucf	ucf/changeprompt	select	keep_current

I also have a preseed-hack file where I run some things.

Also in preceed.cfg:

# Run final commands in target install
d-i preseed/late_command string \
    in-target tl-preseed-hack ;\
    in-target rm -f /usr/bin/tl-preseed-hack ;

So you see, the tl-preseed-hack file let's me move configs and stuff around as I please. I use it to move the final configs into place, and also to remove some leftovers that live-build doesn't clean up.

So far I've never experienced any of these configs being overwritten in any upgrade. But that behavior can be avoided anyways, by a setting in "/etc/utc.conf"

# Force the installed file to be retained. The default is have this
# variable unset, which makes the script ask in case of doubt. To
# change the default behavior, uncomment the following line and set
# the value to YES
#
conf_force_conffold=YES

If someone wants to make sure that their custom configs isn't overwritten by new configs in upgrades, they could use this setting, and they shouldn't even be asked. The existing configs should be kept.

But off course, there could be a reason why you need the diversion anyways.., that I can't see right now, as I'm not all that into the details about how Bunsen is put together.

Horizon_Brave · 2016-03-08 01:11:57

spacex wrote:

# Run final commands in target install
d-i preseed/late_command string \
    in-target tl-preseed-hack ;\
    in-target rm -f /usr/bin/tl-preseed-hack ;

I feel like the biggest newbie right now.

hhh · 2016-03-08 02:44:45

Horizon_Brave wrote:

spacex wrote:

# Run final commands in target install
d-i preseed/late_command string \
    in-target tl-preseed-hack ;\
    in-target rm -f /usr/bin/tl-preseed-hack ;

I feel like the biggest newbie right now.

Don't. It's not that alien.

d-i is the Debian Installer (which BL uses), and preseed does what it says, it let's you set some things up before the Live ISO gets built. In this case he's running 2 commands at the very end of the installer portion of live-build, running his script and then removing the file.

Reference...
https://wiki.debian.org/DebianInstaller/FAQ
https://packages.debian.org/jessie/misc/live-build

Horizon_Brave · 2016-03-08 03:39:29

hhh wrote:

Don't. It's not that alien.
d-i is the Debian Installer (which BL uses), and preseed does what it says, it let's you set some things up before the Live ISO gets built. In this case he's running 2 commands at the very end of the installer portion of live-build, running his script and then removing the file.
Reference...
https://wiki.debian.org/DebianInstaller/FAQ
https://packages.debian.org/jessie/misc/live-build

Thanks hhh... jeez.. in the last day following this issue, I discovered the existence of Debian Alternatives, dpkg diversions and now this d-i and preseeding business.... How deep does one linux distro go?? I can't keep up!

Anyway, would shifting the background to alternatives, then negate the need for the diversion method? or would the /etc/lightdm/lightdm-gtk.conf still need to be diverted to the lightdm-gtk.conf.bunsen?

Last edited by Horizon_Brave (2016-03-08 03:40:05)

johnraff · 2016-03-10 03:34:58

Horizon_Brave wrote:

Wouldn't it be wise to create a usr/share/bunsen/alternatives directory for all and future alternatives we create later on?

It sounds sensible, but different alternatives are different kinds of files. For example bl-text-editor is an executable that has to go in /usr/bin, desktop-grub (a standard Debian alternative) lives in /usr/share/images/desktop-base/desktop-grub.png...

Also, as a side question, if the creation of alternatives is used to solve this, would the user then need to set his wallpapers with the update-alternatives command each time?

This isn't about wallpapers, it's the login background for LightDM. Wallpapers belong to the user so changing them is very easy and can be done in all kinds of ways. The login background is a system setting.

johnraff · 2016-03-10 03:41:58

spacex wrote:

johnraff wrote:
The diversion of /etc/lightdm/lightdm-gtk-greeter.conf is necessary to put in our custom configurations for LightDM.
I'm sorry, but I don't understand why. I'm able to put in my custom LightdDM configuration in live-build, without doing that

Diversions are more flexible. If a user wants to uninstall the bunsen package which put the diversion in, they get back the standard config file which the package installed. Also, it's not at all difficult to set this up in the debian package source.

----

BTW maybe /etc/utc.conf was supposed to be /etc/ucf.conf?

Last edited by johnraff (2016-03-10 04:15:16)

Horizon_Brave · 2016-03-10 04:03:14

johnraff wrote:

Horizon_Brave wrote:
Wouldn't it be wise to create a usr/share/bunsen/alternatives directory for all and future alternatives we create later on?
It sounds sensible, but different alternatives are different kinds of files. For example bl-text-editor is an executable that has to go in /usr/bin, desktop-grub (a standard Debian alternative) lives in /usr/share/images/desktop-base/desktop-grub.png...

Ah! That does make sense...

Also, as a side question, if the creation of alternatives is used to solve this, would the user then need to set his wallpapers with the update-alternatives command each time?

This isn't about wallpapers, it's the login background for LightDM. Wallpapers belong to the user so changing them is very easy and can be done in all kinds of ways. The login background is a system setting.

Okay, you lost me... What would the difference be between the login background..and the login wallpaper. And why is it so exclusive to the system and not configurable as easily as a normal desktop wallpaper or 'background'?

Last edited by Horizon_Brave (2016-03-10 04:04:20)

johnraff · 2016-03-10 04:17:49

^Sorry, by wallpaper I meant the user's desktop wallpaper. "background" and "wallpaper" are usually interchangable. The point is that at the login screen we haven't yet entered the user's personal space and all settings are at system level, to apply to all users.

damo · 2016-03-10 04:19:30

Horizon_Brave wrote:

...
Okay, you lost me... What would the difference be between the login background..and the login wallpaper. And why is it so exclusive to the system and not configurable as easily as a normal desktop wallpaper or 'background'?

The login settings have to be system settings, because the user hasn't been established until they have logged in. You can't have per-user login settings - "That does not compute, Captain."

Wallpaper, background, whatever. The lightdm screen isn't the same as the window manager session, which is started by lightdm after the user is logged in, so you might expect backgrounds to be handled differently.

I find the background is easily configurable, as is the grub boot screen background (if you know where it is set, of course )

#1 2016-03-06 03:43:08

Add Debian alternative for login background?

#2 2016-03-06 05:17:11

Re: Add Debian alternative for login background?

#3 2016-03-06 06:28:13

Re: Add Debian alternative for login background?

#4 2016-03-06 09:58:11

Re: Add Debian alternative for login background?

#5 2016-03-06 15:06:55

Re: Add Debian alternative for login background?

#6 2016-03-06 18:10:14

Re: Add Debian alternative for login background?

#7 2016-03-07 02:11:43

Re: Add Debian alternative for login background?

#8 2016-03-07 06:22:08

Re: Add Debian alternative for login background?

#9 2016-03-07 08:18:21

Re: Add Debian alternative for login background?

#10 2016-03-07 10:07:45

Re: Add Debian alternative for login background?

#11 2016-03-07 15:52:58

Re: Add Debian alternative for login background?

#12 2016-03-08 00:19:17

Re: Add Debian alternative for login background?

#13 2016-03-08 01:11:57

Re: Add Debian alternative for login background?

#14 2016-03-08 02:44:45

Re: Add Debian alternative for login background?

#15 2016-03-08 03:39:29

Re: Add Debian alternative for login background?

#16 2016-03-10 03:34:58

Re: Add Debian alternative for login background?

#17 2016-03-10 03:41:58

Re: Add Debian alternative for login background?

#18 2016-03-10 04:03:14

Re: Add Debian alternative for login background?

#19 2016-03-10 04:17:49

Re: Add Debian alternative for login background?

#20 2016-03-10 04:19:30

Re: Add Debian alternative for login background?

Board footer