Installs of bunsen-conky after first setup

[johnraff]

If a user installs BunsenLabs without bunsen-conky and then installs that package later, all the conky files will get installed to the 'skel' directory but will not reach the user's HOME because bl-user-setup only runs once. (Otherwise it would be overwriting the user's personal config files.)

So what's the best way to handle this?

A postinstall script to copy in just the conky files? But that would be run by root, and wouldn't necessarily know which user wanted the files, unless everyone got them.

A user-run script in /usr/bin to do the job? The user(s) would have to be told about it somehow.

Other method?

[Sector11]

I figured it would be an automatic install ... hmmmmmmm,

[johnraff]

Yes, if bunsen-conky went in at the start it would get copied from skel along with everything else, but that only happens with the initial user setup. Obviously, we can't keep on overwriting the user's personal files - it would be rather rude...

So my best guess at the moment is to provide a bl-install-conky script with bunsen-conky, that the user can, er... use to copy in the files when they want to. Maybe add a helpfile too.

[Sector11]

That would work .... something in the bl-welcome script.

[johnraff]

Well, the welcome script won't necessarily have bunsen-conky installed when it runs. I was thinking maybe a separate script, packaged along with bunsen-conky. As long as we can think of a good way to make sure users know they need to run it!

[Sector11]

Sounds like you are saying that the bunsen-conky package is an "option" that users will have rather than installed automatically on installing BL. As it sits now the Conky Chooser can be found in:

System » Conky » Conky Chooser

and is installed automatically. Is there a plan on changing that? Or am I missing something?

[johnraff]

Well my first post said: If a user installs BunsenLabs without bunsen-conky and then installs that package later... so I was referring to the possibility that bunsen-conky might not have been installed at the start. I think we should be offering users the maximum freedom to pick and choose, avoiding unnecessary dependencies as much as possible. (I've just been to some trouble moving a couple of scripts from bunsen-utilities to bunsen-configs so that bunsen-utilities wouldn't need to be a dependency of bunsen-configs.)

The Conky Chooser comes with bunsen-utilities. As far as I know both bunsen-conky and bunsen-utilities will be in the default BL install. I still think we should allow users not to install things they don't want (remember Gnome!), and to make things easy for them if they decide to add something later after all. Also, thinking about possible "lite" versions in the future.

[Sector11]

OK, I can agree with that - once of my gripe's with BL (not yet voiced) was trying to remove xscreensaver that I don't have on any system and it wanted to remove bunsen-utilities

I was not pleased. Is there a way to make bunsen-utilities something totally independent of what Debian8 installs? Remember - I'm the noob here is this area of expertise.

[johnraff]

Ah that's because bl-lock (inside bunsen-utilities) needs xscreensaver. Maybe it could be changed to use 13lock instead - but that would then become a dependency of bunsen-utilities instead. In fact b-u depends on a number of other packages needed by the different scripts so it would be impossible to make it dependency-free I think.

BTW another reason I wanted to make bunsen-conky's installation independent of the BL install was for the people who might not be running BunsenLabs at all, but still wanted bunsen-conky.

[Sector11]

That's a GREAT idea, the big draw for bunsen-conky isn't so mush the conkys as it is damo's complete re-write of the zenity script I started with that really put the cherry on the cake.

EDIT: Add an OB Menu entry to download the bunsen-conky ZIP from GitHub. That should should do it quite nicely.

OK, from the noob in me. Is there a simple way to break bunsen-utilities in two? bunsen-utilities-desktop bunsen-utilities-laptop

Because bl-lock or 13lock are not required on a desktop. I realize it's late in the game and a noob question but I'm not so busy with BL Cony at the moment. :)

[johnraff]

bunsen-conky recommends bunsen-utilities, which contains damo's scripts, so most people will get them too.

It's not so hard to break packages up, or combine them - bunsen-utilities was put together from several packages which seemed too small to be packages by themselves.

Agreed, a lock isn't needed on a home desktop. In a shared environment like an office people would probably want one though. I don't use it, but don't find it a particular problem having a lock on my machine. It's not that much disk space.

I also enjoy screensavers when the screen is idle, but not everyone shares that taste. On #! the screensavers are disabled by default (easily turned on) and xscreensaver seems to be installed mainly for the lock. It's about 2MB. We could replace it by a smaller lock-only package but I wonder if that much disk space would be saved? Most peoples' objections to xscreensaver seem to be more focussed on the ugly lock screen.

[Sector11]

Well, there are a lot of apps installed on any distro that most people aren't even know are there so I guess a few MB in this day and age ... I did turn xscreensaver off so it's not a biggie. Just surprised that I could delete it in Waldorf and simply not install it in Wally-jr. No problem en the end.

Example - the calculator - I deleted that since xcalc come with another utility that's in #!, haven tested to see if it's in wally or bunsen though. It does more than I need these days.

Plus there is bc not sure if that is installed by default but I use it in a bash script: calc

#!/bin/bash
#
bc << END
scale=5
$@
END

---

  18 May 15 | 23:27:42 ~
    $ calc 23*987/4
5675.25000
  18 May 15 | 23:27:54 ~
    $ 

[johnraff]

I just tried apt-get -s remove xscreensaver on Waldorf and it wanted to remove cb-lock too. (I guess you didn't particularly mind losing that.) Now cb-lock is bundled in bunsen-utilities that dependency has been inherited.

There are a lot of small packages in BL, inherited from #!, and some of them could perhaps be dropped from the default install if they don't break anything. Of course it was Philip's personal setup so he put in all the things he wanted.

[Sector11]

That's one thing people keep forgetting - #! was Philips 'personal' setup. And you're right, I wouldn't have minded loosing cb-lock (or bl-lock).

bl-utilities is a metapackage isn't it? Is there a way to list the file it installs? Because taking bl-utilities out just might remove more.

[johnraff]

bunsen-utilities isn't a metapackage - it contains the scripts that used to be in those various small packages (which are now obsolete), plus some more that have been added, mostly by damo, including conkyzen. You can see the files here: https://github.com/BunsenLabs/bunsen-utilities All those bl-* scripts go into /usr/bin You can check the install file in debian/ to see where the files in a package will be installed. For example: https://github.com/BunsenLabs/bunsen-utilities/blob/master/debian/bunsen-utilities.install

[johnraff]

So my best guess at the moment is to provide a bl-install-conky script with bunsen-conky

Now done.