RFT The "devel" section in the current bl-welcome

johnraff · 2016-09-22 07:14:13

The "deuterium" version of bl-welcome should be out soon, but it occurred to me that the later "devel" half of the current script, which was imported from CrunchBang almost as-is, might not have been tested much.

If anyone has used the options there, reports on whether things went OK or not would be appreciated.
The LAMP stack occurs to me, along with the Debian packaging tools page.

In particular, after installing pbuilder (and many others), the latter has:

bl-welcome wrote:

MIRRORSITE=http://ftp.de.debian.org/debian
DISTRIBUTION=jessie
COMPONENTS="main contrib non-free"
Create pbuilder environment now?

Which would run 'sudo pbuilder create'. The mirror has already been changed to httpredir.debian.org in deuterium, but I'm wondering what users would want to make use of this shortcut? Those who have already read man pbuilder would likely know how to create an environment, and new pbuilder users would be left after 10~15 minutes without a clue what to do next.

Just drop that "Create environment" offer?

Any other "devel" items that don't work or seem unhelpful?

Bearded_Blunder · 2016-09-22 11:34:58

FWIW I'm considering setting up a LAMP stack soon, to replace a somewhat resource hungry WAMP stack, and had already decided to skip using that to do it, simply so I'd have a better understanding of what I had by setting it up manually. I wonder how many other LAMP users take this approach for the same reasons?

damo · 2016-09-22 11:50:31

My brother is a web-developer, and the first thing he does after an install is set up LAMP. When I showed him #! he was super-impressed that it asked if he wanted LAMP, and the script did the heavy-lifting!

He recently installed BL, and is very happy with the way it dealt with LAMP

Bearded_Blunder · 2016-09-22 11:53:08

Interesting, I may try it then

geekosupremo · 2016-09-22 18:11:08

The LAMP is fine by me. I've had no trouble with it so far.

It would be kinda nice if we could pick which of SVN we installed instead of the raft that comes now. Just a nit pick.

Last edited by geekosupremo (2016-09-22 18:11:38)

damo · 2016-09-22 18:24:45

geekosupremo wrote:

...
It would be kinda nice if we could pick which of SVN we installed instead of the raft that comes now. Just a nit pick.

That has bugged me a bit as well. In fact, is there any need for version control tools, pbuilder etc? Those who need them know how to get them already.

geekosupremo · 2016-09-22 19:43:47

While we're talking about devel environ, maybe it would be worth looking at something like the CaddyServer project for the times we just need a small easy local web server.

damo · 2016-09-22 20:01:30

geekosupremo wrote:

While we're talking about devel environ, maybe it would be worth looking at something like the CaddyServer project for the times we just need a small easy local web server.

Or do it with a python one-liner invoking the SimpleHTTPServer module, which should already be installed?

geekosupremo · 2016-09-22 20:51:59

damo wrote:

do it with a python one-liner invoking the SimpleHTTPServer module, which should already be installed?

OH! Learning new stuff! Thanks @damo!!

johnraff · 2016-09-23 02:41:16

damo wrote:

Those who need them know how to get them already.

This could be applied to the whole "devel" section, really. But, OTOH, damo you mentioned your brother who appreciated having LAMP set up for him, even though he of course could have done it himself.

Remembering #!'s roots as Phillip Newborough's personal setup, the things in Dev were presumably all the things he would do immediately after a new install, and enjoyed having done for him automatically.

Does the Dev section as it now is fit the needs of a reasonably big section of users?
(OP: does it all still work OK?)
What parts of it (if any) could now reasonably be dropped?

lcafiero · 2016-09-23 03:14:39

johnraff wrote:

Does the Dev section as it now is fit the needs of a reasonably big section of users?
(OP: does it all still work OK?)
What parts of it (if any) could now reasonably be dropped?

Because I'm nowhere near being a software developer or a programmer, the Dev section was always a mystery to me at the end of both the #! and BL install processes. But I always installed the tools anyway for basically two reasons: a.) I didn't want to miss anything, and b.) there might be a time when I might just actually use a tool (or tools) involved, and it's good that it was included in the install in the first place.

Does it fit the needs of a "reasonably big section of users," as you ask? I would venture to say "yes," although the average non-developer user (he says, looking in a mirror) may not have a need for most, or possibly any, of it. Developers among you all, on the other hand, may want to keep it, and you would know better what works best and what doesn't.

I just thought I'd throw in a non-developer perspective on it.

Also, +1,000,000 for the LAMP stack setup. Yeah, I could probably/possibly/maybe do it myself without looking like Wile E. Coyote after an ACME product malfunction, but it's so nice to have it done during the course of an install. So absolutely keep that.

Last edited by lcafiero (2016-09-23 03:18:06)

johnraff · 2016-10-19 03:58:01

johnraff wrote:

after installing pbuilder (and many others), the latter has (some code) which would run 'sudo pbuilder create' .... I'm wondering what users would want to make use of this shortcut? Those who have already read man pbuilder would likely know how to create an environment, and new pbuilder users would be left after 10~15 minutes without a clue what to do next.
Just drop that "Create environment" offer?

I'm thinking more and more that offering to create a "pbuilder environment" of several GB isn't something that bl-welcome needs to be doing.

OTOH:

damo wrote:

is there any need for version control tools, pbuilder etc? Those who need them know how to get them already.

In two minds about this one. Just drop it is an attractive option, but there's the all-the-trouble-it-saves argument, as with the LAMP install option, which most people would like to keep...

tknomanzr · 2016-10-19 18:08:34

I was actually impressed that you offered pbuilder to be quite honest. I suppose it depends how many forehead to desk maneuvers installing it involves. I liked the LAMP install option because that process can take some time to get setup correctly. If pbuilder is like that then keep it.

I'd say when it comes to the developer section, stick with the tools that we use for BL, with the exception of the LAMP stack offering. I mean I could say we need an alternative to LAMP with nginx/django but 5 minutes on the django site will get you up and running with it.

Truthfully, these options could also be moved into pipe menus in a developer section of the menu and out of bl-welcome altogether. That would give you more modular control over the install process. I am sitting here looking at bl-wecome offering to install bunsen-meta-vcs, which offers to install way more than it should. Here is the total package list:

The following NEW packages will be installed:
  bsd-mailx bunsen-meta-vcs bzr bzrtools cvs cvsps exim4 exim4-base
  exim4-config exim4-daemon-light git-cvs git-email git-gui git-svn gitk
  javascript-common libapr1 libaprutil1 libauthen-sasl-perl
  libconfig-inifiles-perl libdbd-sqlite3-perl libdbi-perl libdigest-hmac-perl
  libemail-valid-perl libio-socket-inet6-perl libio-socket-ssl-perl
  libjs-excanvas libjs-jquery liblist-moreutils-perl liblockfile-bin
  liblockfile1 libmailtools-perl libnet-dns-perl libnet-domain-tld-perl
  libnet-ip-perl libnet-libidn-perl libnet-smtp-ssl-perl libnet-ssleay-perl
  libserf-1-1 libsocket6-perl libsvn-perl libsvn1 libtcl8.6
  libterm-readkey-perl libtk8.6 liburi-perl libyaml-libyaml-perl libyaml-perl
  mercurial mercurial-common python-bzrlib python-configobj python-gpgme
  python-httplib2 python-keyring python-launchpadlib python-lazr.restfulclient
  python-lazr.uri python-oauth python-secretstorage python-simplejson
  python-subversion python-wadllib subversion subversion-tools svn2cl tcl
  tcl8.6 tk tk8.6 xsltproc

This stuff could be broken down into developer pipe menus and offered on an as needed basis. We could then offer to setup a proper git environment, etc. I also am seeing mail setup in there with exim4, etc. That probably deserves more thought as to how to properly setup the environment. I mean I usually setup just enough to get cron messages but the process to properly set it up looks mystifying to me.

In the end, this would probably involve way more work than just lumping it all into bl-welcome but also, I believe is the proper way to set it up.

johnraff · 2016-10-20 09:53:05

tknomanzr wrote:

I was actually impressed that you offered pbuilder to be quite honest. I suppose it depends how many forehead to desk maneuvers installing it involves. I liked the LAMP install option because that process can take some time to get setup correctly. If pbuilder is like that then keep it.

All bl-welcome does is offer to install pbuilder (apt-get) then offer to run a simple command 'sudo pbuilder create'. About LAMP, to be honest, apart from installing apache, php and mysql only a very minor bit of setup gets done too. There's still more work needed to set a server up.

Anyway, I can see the argument that getting a whole list of apps installed at once - some of them you might not use for a while, but they're mostly small - saves some time even for the experienced developer, so can see the value of an "install developer tools" page. I do feel like taking out that 'pbuilder create' offer though - it takes a long time to run and occupies a lot of disk space. Someone who is ready to use pbuilder would surely be capable of running that command themselves?

About the "VCS" meta - if you think it's too big, please suggest a shorter list of apps to bring in. I'm not all that keen on creating a collection of smaller metas or pipemenu items though (see below).

This stuff could be broken down into developer pipe menus and offered on an as needed basis. We could then offer to setup a proper git environment, etc.... I also am seeing mail setup in there with exim4, etc. That probably deserves more thought as to how to properly setup the environment. I mean I usually setup just enough to get cron messages but the process to properly set it up looks mystifying to me.
In the end, this would probably involve way more work than just lumping it all into bl-welcome...

That's the point. Would it be worth all that work?

Recently I'm starting to feel averse to putting a lot more stuff into pipemenus.

1) Unlike bl-welcome, which you only see when you run it, unused pipemenu items are in your face every time you open the menu. At one time I was all in favour of moving the offer to install bunsen-images-extra from bl-welcome to the graphics pipemenu, but started to wonder just how annoying it might get to see that every time you want to open GIMP. Maybe if such installation offers were all tucked away in "install" sub-menus it might be OK...

2) More than (1), I'm starting to think we're already doing quite enough hand-holding in the system and some of such automation might be better replaced by tutorials and How-To's on the forum.

3) Even more than (1) and (2), is the "way more work" factor. I don't feel like doing that at all at the moment - of course anyone else is welcome to take up a favourite aspect and make a pipemenu for it - but right now this thread was really more about taking stuff out of bl-welcome, rather than putting even more stuff into pipemenus.

dolly · 2016-10-20 12:40:18

I do agree with johnraff here, especially what he says about hand holding and pipe menus. The things in the bl-welcome script that I do not want, I just skip.

tknomanzr · 2016-10-20 15:20:50

Truth be told, git and subversion will most likely cover 99+ % of Linux version control use cases. So it would probably be ok to toss mercurial and cvs unless somebody speaks up. Even subversion is not used ALL that much any more. I am on the fence in regards to git-gui. I have never actually used it and feel it is better for me at least to use the tool from the command line. It is responsible for pulling in the tcl and tk packages.

Git ends up on my systems very early (sometimes even while still in console) so that I can pull all my various scripts, etc down into a new system. So it ends up installed as soon as I can get to the console/terminal and I dont think I have ever installed it from bl-welcome. I just annoy myself by having to look up how to setup the environment again despite having been through it 1200 times. I think it is a manifestation of sometimers syndrome. Sometimes I remember stuff and sometimes I dont. So you can't blame me for asking

In regards to the LAMP stack, you are correct, of course. But it has always served the useful purpose of giving a quick and dirty web development stack for me at least.

If we do not already pull it in somewhere else, then build-essential might be useful to offer.

johnraff · 2016-10-21 02:49:06

Just for reference, from bunsen-welcome's debian/control file, here's what the big BL dev metapackages pull in:

Package: bunsen-meta-vcs
Architecture: all
Depends:
 git,
 git-gui,
 git-cvs,
 git-svn,
 git-email,
 mercurial,
 subversion,
 subversion-tools,
 bzr,
 bzrtools,
 cvs
Description: BunsenLabs version control meta package
 Installs various version control tools.

Package: bunsen-meta-lamp
Architecture: all
Depends:
 apache2,
 apache2-utils,
 mysql-server,
 php5,
 php-pear,
 php5-gd,
 php5-mysql,
 php5-imagick,
 php5-curl,
 curl,
 phpmyadmin,
 rsync,
 cronolog
Description: BunsenLabs lamp meta package
 Installs various web server tools.

Package: bunsen-meta-packaging
Architecture: all
Depends:
 build-essential,
 debhelper,
 cdbs,
 dh-make,
 diffutils,
 patch,
 gnupg,
 fakeroot,
 lintian,
 devscripts,
 pbuilder,
 dpatch,
 dput,
 quilt
Description: BunsenLabs packaging meta package
 Installs various Debian packaging tools.

Actually, in terms of disk space the number of packages isn't everything. The LibreOffice meta, for example, only depends on libreoffice and libreoffice-gtk, but of course libreoffice itself is a meta, and installing bunsen-meta-libreoffice will bring in a truckload of packages taking up hundreds of MB. Of course on modern hard disks this is no big issue, and developers should expect to put stuff in by the GB, I'd have thought.

-----
btw
It ocurred to me today that an alternative to more pipemenus in corners of the openbox root-menu might be a quite separate "system" menu, to be brought up by some keyboard shortcut, or xdotool simulation. That would keep it more out of users' way, though existing users would have to add it to menu.xml and rc.xml manually.

One advantage of pipemenus over hard-coded user menus is that they can be tweaked from the system side at any time by a package upgrade. The disadvantage is that they are much harder for users to customize.

johnraff · 2016-10-21 02:57:41

tknomanzr wrote:

Truth be told, git and subversion will most likely cover 99+ % of Linux version control use cases. So it would probably be ok to toss mercurial and cvs unless somebody speaks up. Even subversion is not used ALL that much any more.

Agreed. Probably just CLI Git is all most people would need. Which would suggest just dropping the VCS metapackage?

I just annoy myself by having to look up how to setup the environment again despite having been through it 1200 times. I think it is a manifestation of sometimers syndrome.

Exactly. People who are doing certain tasks daily or weekly don't need help. It's person/task combinations that occur, say, once or twice a year where a bit of automation is nice. (Same applies to GUI vs keyboard shortcuts - keyboard for frequent stuff, GUI for occasional jobs.)

Of course, what tasks come in which category is different for different people, so we need to know if something we're planning to automate hits the spot for a reasonably big number of people.

Horizon_Brave · 2016-10-21 15:39:52

So just to catch up with this, and avoiding some confusion, I just update/upgraded and was pushed a bunsen-welcome package of 8.11-1 . This is the current Hydrogen version correct? When was this updated? Because I could have sworn I ran a previous upgrade only days prior and didn't get anything.

damo · 2016-10-21 17:19:19

Bunsenlabs Repository Index wrote:

bunsen-welcome
Version: 8.11-1 (01/10/2016)

https://pkg.bunsenlabs.org/repoidx.html … en-welcome

#1 2016-09-22 07:14:13

RFT The "devel" section in the current bl-welcome

#2 2016-09-22 11:34:58

Re: RFT The "devel" section in the current bl-welcome

#3 2016-09-22 11:50:31

Re: RFT The "devel" section in the current bl-welcome

#4 2016-09-22 11:53:08

Re: RFT The "devel" section in the current bl-welcome

#5 2016-09-22 18:11:08

Re: RFT The "devel" section in the current bl-welcome

#6 2016-09-22 18:24:45

Re: RFT The "devel" section in the current bl-welcome

#7 2016-09-22 19:43:47

Re: RFT The "devel" section in the current bl-welcome

#8 2016-09-22 20:01:30

Re: RFT The "devel" section in the current bl-welcome

#9 2016-09-22 20:51:59

Re: RFT The "devel" section in the current bl-welcome

#10 2016-09-23 02:41:16

Re: RFT The "devel" section in the current bl-welcome

#11 2016-09-23 03:14:39

Re: RFT The "devel" section in the current bl-welcome

#12 2016-10-19 03:58:01

Re: RFT The "devel" section in the current bl-welcome

#13 2016-10-19 18:08:34

Re: RFT The "devel" section in the current bl-welcome

#14 2016-10-20 09:53:05

Re: RFT The "devel" section in the current bl-welcome

#15 2016-10-20 12:40:18

Re: RFT The "devel" section in the current bl-welcome

#16 2016-10-20 15:20:50

Re: RFT The "devel" section in the current bl-welcome

#17 2016-10-21 02:49:06

Re: RFT The "devel" section in the current bl-welcome

#18 2016-10-21 02:57:41

Re: RFT The "devel" section in the current bl-welcome

#19 2016-10-21 15:39:52

Re: RFT The "devel" section in the current bl-welcome

#20 2016-10-21 17:19:19

Re: RFT The "devel" section in the current bl-welcome

Board footer