Debian Bug report logs - #758116
tasksel: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

Package: src:blends; Maintainer for src:blends is Debian Pure Blend Team <debian-blends@lists.debian.org>;

Reported by: Andreas Tille <tille@debian.org>

Date: Thu, 14 Aug 2014 11:27:01 UTC

Severity: normal

Tags: d-i

Fixed in version blends/0.6.93

Done: Ole Streicher <olebole@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, debian-blends@lists.debian.org, debian-devel@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#758116; Package tasksel. (Thu, 14 Aug 2014 11:27:06 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
New Bug report received and forwarded. Copy sent to debian-blends@lists.debian.org, debian-devel@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 14 Aug 2014 11:27:06 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: tasksel
Version: 3.14.1
Severity: normal
Tags: d-i


Hi,

beeing inspired by bug #758096 (I was asked to separate this topic from
the topic of this bug) and the recent discussion on Blends list, I'd
like to add a pointer to the thread basically starting here:

   https://lists.debian.org/debian-blends/2014/08/msg00004.html
 
Currently we can provide tasksel control files in the following
Blends (packages):

   Debian Edu     (edu-tasks)
   Debian Games   (games-tasks)
   Debian GIS     (gis-tasks)
   Debian Junior  (junior-tasks)
   Debian Med     (med-tasks)
   Debian Science (science-tasks)
   DebiChem       (debichem-tasks)

The packages contain a file

   /usr/share/tasksel/descs/<blendname>-tasks.desc

and the usual stuff in /usr/share/doc/<pkgname> but nothing else.  They
are exclusively designed as tasksel input.

IMHO it would do a nice service to our users to promote these topics on
our installers at the time when tasks will be selected.

Kind regards

       Andreas.


-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages tasksel depends on:
ii  apt                     0.9.7.9+deb7u2
ii  debconf [debconf-2.0]   1.5.49
ii  liblocale-gettext-perl  1.05-7+b1
ii  perl-base               5.14.2-21+deb7u1
ii  tasksel-data            3.14.1

tasksel recommends no packages.

tasksel suggests no packages.

-- debconf information excluded

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#758116; Package tasksel. (Thu, 14 Aug 2014 15:21:05 GMT) (full text, mbox, link).

Acknowledgement sent to Yaroslav Halchenko <yoh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 14 Aug 2014 15:21:05 GMT) (full text, mbox, link).

Message #10 received at 758116@bugs.debian.org (full text, mbox, reply):

On Thu, 14 Aug 2014, Andreas Tille wrote:

> IMHO it would do a nice service to our users to promote these topics on
> our installers at the time when tasks will be selected.

+100

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,            Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#758116; Package tasksel. (Tue, 26 Aug 2014 11:30:05 GMT) (full text, mbox, link).

Acknowledgement sent to 758116@bugs.debian.org, debian-blends@lists.debian.org:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 26 Aug 2014 11:30:05 GMT) (full text, mbox, link).

Message #15 received at 758116@bugs.debian.org (full text, mbox, reply):

Cc: Debian Edu Project List <debian-edu@lists.debian.org>, debian-devel-games@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, "Debian Jr. Project List" <debian-jr@lists.debian.org>, Debian Med Project List <debian-med@lists.debian.org>, Debian Science List <debian-science@lists.debian.org>, DebiChem Project <debichem-devel@lists.alioth.debian.org>, pkg-multimedia-maintainers@lists.alioth.debian.org, 3dprinter-general@lists.alioth.debian.org, debian-accessibility@lists.debian.org, debian-astro@lists.debian.org

Hi,

yesterday I joined the videostream of the installer BoF at DebConf[1].
I also became a bit involved via IRC.  Joey Hess raised the question
about the criteria to add a Blend or not.  I answered "all in the list
of the bug report #758116" which IMHO fits the criterion of "actively
maintained and some valuable content for users".

I think it should be also a criterion that the team behind the Blend
confirms that they are interested and so I'm hereby pinging all lists in
question to ask you for confirmation.  I have set Reply-To to the bug
report and the general Blends list in case you are interested in further
discussion with other Blends.

Any input is welcome to make sure users will realise the fruits of your
great work at the earliest point in time.

Kind regards

     Andreas.

[1] https://summit.debconf.org/debconf14/meeting/44/debian-installer-and-cd-bof/

-- 
http://fam-tille.de

Acknowledgement sent to Sebastiaan Couwenberg <sebastic@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 26 Aug 2014 11:45:05 GMT) (full text, mbox, link).

Message #20 received at 758116@bugs.debian.org (full text, mbox, reply):

On 08/26/2014 01:27 PM, Andreas Tille wrote:
> I think it should be also a criterion that the team behind the Blend
> confirms that they are interested and so I'm hereby pinging all lists in
> question to ask you for confirmation.

I second the inclusion of Debian GIS tasks, as I would love for the
Debian GIS tasks to be installable via d-i.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 26 Aug 2014 12:12:06 GMT) (full text, mbox, link).

Message #25 received at 758116@bugs.debian.org (full text, mbox, reply):

Le Tue, Aug 26, 2014 at 01:27:23PM +0200, Andreas Tille a écrit :
> Hi,
> 
> yesterday I joined the videostream of the installer BoF at DebConf[1].
> I also became a bit involved via IRC.  Joey Hess raised the question
> about the criteria to add a Blend or not.  I answered "all in the list
> of the bug report #758116" which IMHO fits the criterion of "actively
> maintained and some valuable content for users".
> 
> I think it should be also a criterion that the team behind the Blend
> confirms that they are interested and so I'm hereby pinging all lists in
> question to ask you for confirmation.  I have set Reply-To to the bug
> report and the general Blends list in case you are interested in further
> discussion with other Blends.
> 
> Any input is welcome to make sure users will realise the fruits of your
> great work at the earliest point in time.

Hi Andreas, Joey and everybody,

I am sure that it would be great for Debian Med to have the Blends as
first-class citizens in the Debian Installer.  While it is not difficult to
install the metapackages by hand, I expect that having it as an option in the
installer will help convincing people to give it a try.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Acknowledgement sent to Filippo Rusconi <lopippo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 26 Aug 2014 13:06:08 GMT) (full text, mbox, link).

Message #30 received at 758116@bugs.debian.org (full text, mbox, reply):

Greetings, Fellow Debianites,

On Tue, Aug 26, 2014 at 01:27:23PM +0200, Andreas Tille wrote:
>Hi,
>
>yesterday I joined the videostream of the installer BoF at DebConf[1].
>I also became a bit involved via IRC.  Joey Hess raised the question
>about the criteria to add a Blend or not.  I answered "all in the list
>of the bug report #758116" which IMHO fits the criterion of "actively
>maintained and some valuable content for users".
>
>I think it should be also a criterion that the team behind the Blend
>confirms that they are interested and so I'm hereby pinging all lists in
>question to ask you for confirmation.  I have set Reply-To to the bug
>report and the general Blends list in case you are interested in further
>discussion with other Blends.
>
>Any input is welcome to make sure users will realise the fruits of your
>great work at the earliest point in time.

Yes, I have to say that I would find it awesome if we could list at
install time the blends that are available. In my opinion, this
feature would undoubtedly help the user and give the feeling that
"things are cleverly organised in Debian" and that "everything is made
to simplify the system installation", which is of great importance if
we think that Debian still has the reputation of being difficult to
deal with at install time.

Thanks, Andreas to bring this forward for us not at the DebConf or not
immediately involved with the installer-related topics.

Cheers,
Filippo

-- 
Filippo Rusconi, PhD - public crypto key 7694CF42@ pgp.mit.edu
Researcher at CNRS and Debian Developer <lopippo@debian.org>
Author of ``massXpert''     at http://www.massxpert.org

Acknowledgement sent to JOSEFSSON Erik <erik.josefsson@europarl.europa.eu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 26 Aug 2014 14:39:05 GMT) (full text, mbox, link).

Message #35 received at 758116@bugs.debian.org (full text, mbox, reply):

Hello! (sorry for top posting)

DebianParl is a blend that could also be in taskel, no?

https://wiki.debian.org/DebianParl

Best regards.

//Erik

-----Original Message-----
From: Charles Plessy [mailto:plessy@debian.org] 
Sent: 26 August 2014 14:09
To: 758116@bugs.debian.org; debian-blends@lists.debian.org
Subject: Re: Please be verbose whether you would like to get your Blend promoted by tasksel

Le Tue, Aug 26, 2014 at 01:27:23PM +0200, Andreas Tille a écrit :
> Hi,
> 
> yesterday I joined the videostream of the installer BoF at DebConf[1].
> I also became a bit involved via IRC.  Joey Hess raised the question
> about the criteria to add a Blend or not.  I answered "all in the list
> of the bug report #758116" which IMHO fits the criterion of "actively
> maintained and some valuable content for users".
> 
> I think it should be also a criterion that the team behind the Blend
> confirms that they are interested and so I'm hereby pinging all lists in
> question to ask you for confirmation.  I have set Reply-To to the bug
> report and the general Blends list in case you are interested in further
> discussion with other Blends.
> 
> Any input is welcome to make sure users will realise the fruits of your
> great work at the earliest point in time.

Hi Andreas, Joey and everybody,

I am sure that it would be great for Debian Med to have the Blends as
first-class citizens in the Debian Installer.  While it is not difficult to
install the metapackages by hand, I expect that having it as an option in the
installer will help convincing people to give it a try.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-blends-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: https://lists.debian.org/20140826120926.GA5558@falafel.plessy.net

Acknowledgement sent to Markus Koschany <apo@gambaru.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 26 Aug 2014 14:57:09 GMT) (full text, mbox, link).

Message #40 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 26.08.2014 13:27, Andreas Tille wrote:
[...}
> I think it should be also a criterion that the team behind the Blend
> confirms that they are interested and so I'm hereby pinging all lists in
> question to ask you for confirmation.  I have set Reply-To to the bug
> report and the general Blends list in case you are interested in further
> discussion with other Blends.
> 
> Any input is welcome to make sure users will realise the fruits of your
> great work at the earliest point in time.

Hi,

I would really like to see that the tasks of the Debian Games Blend are
installable via d-i. A package with tasksel descriptions, »games-tasks«,
is already available. Please let me know if there is anything else that
can be done from my side.

Regards,

Markus

[signature.asc (application/pgp-signature, attachment)]

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 26 Aug 2014 15:18:04 GMT) (full text, mbox, link).

Message #45 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

[ replying only to bug + list - hope all are subscribed ]
Quoting JOSEFSSON Erik (2014-08-26 16:27:43)
> Hello! (sorry for top posting)

Feeling sorry is no use.  Consider at least strip fullquote next time.


> DebianParl is a blend that could also be in taskel, no?
> 
> https://wiki.debian.org/DebianParl

DebianParl is a blend, yes, but currently not defined by metapackage(s) 
so cannot technically be included in tasksel.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Ross Gammon <ross@the-gammons.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 26 Aug 2014 19:51:04 GMT) (full text, mbox, link).

Message #50 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Andreas,

Yes. It is a great idea to be able to choose your blend at
installation time. Most of my machines are used for different
purposes, and not to have to remember the name of a meta-package to
install after the initial installation would be fantastic.

It is much easier to tell someone new to install Debian and select
"Debian GIS" from the list, than to refer them to a wiki with
post-installation instructions.

Cheers,

Ross

Acknowledgement sent to Per Andersson <avtobiff@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 26 Aug 2014 23:27:04 GMT) (full text, mbox, link).

Message #55 received at 758116@bugs.debian.org (full text, mbox, reply):

On Tue, Aug 26, 2014 at 1:27 PM, Andreas Tille <andreas@an3as.eu> wrote:
> Hi,
>
> yesterday I joined the videostream of the installer BoF at DebConf[1].
> I also became a bit involved via IRC.  Joey Hess raised the question
> about the criteria to add a Blend or not.  I answered "all in the list
> of the bug report #758116" which IMHO fits the criterion of "actively
> maintained and some valuable content for users".
>
> I think it should be also a criterion that the team behind the Blend
> confirms that they are interested and so I'm hereby pinging all lists in
> question to ask you for confirmation.  I have set Reply-To to the bug
> report and the general Blends list in case you are interested in further
> discussion with other Blends.
>
> Any input is welcome to make sure users will realise the fruits of your
> great work at the earliest point in time.

Since I have revived the Debian Junior blend I also, as previous posters,
think it is a superb idea to be able to easily install this and other blends.

Since I missed the d-i and cd BoF, what is needed to make this happen?
Is there anything I can do to help?


--
Per

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#758116; Package tasksel. (Wed, 27 Aug 2014 07:09:12 GMT) (full text, mbox, link).

Acknowledgement sent to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 27 Aug 2014 07:09:12 GMT) (full text, mbox, link).

Message #60 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Andreas,

[taking all lists except debian-blends and debian-edu off the loop...]

On  Di 26 Aug 2014 13:27:23 CEST, Andreas Tille wrote:

> Hi,
>
> yesterday I joined the videostream of the installer BoF at DebConf[1].
> I also became a bit involved via IRC.  Joey Hess raised the question
> about the criteria to add a Blend or not.  I answered "all in the list
> of the bug report #758116" which IMHO fits the criterion of "actively
> maintained and some valuable content for users".
>
> I think it should be also a criterion that the team behind the Blend
> confirms that they are interested and so I'm hereby pinging all lists in
> question to ask you for confirmation.  I have set Reply-To to the bug
> report and the general Blends list in case you are interested in further
> discussion with other Blends.
>
> Any input is welcome to make sure users will realise the fruits of your
> great work at the earliest point in time.
>
> Kind regards
>
>      Andreas.

I guess this only makes sense if a Debian Edu machine (standalone) can  
be installed via Debian's normal D-I, right?

@Petter: is that possible? Do you know?

Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 27 Aug 2014 08:45:05 GMT) (full text, mbox, link).

Message #65 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Mike,

On Wed, Aug 27, 2014 at 07:08:27AM +0000, Mike Gabriel wrote:
> 
> I guess this only makes sense if a Debian Edu machine (standalone)
> can be installed via Debian's normal D-I, right?

Why do you think only this is would make sense?  IMHO it would make
perfectly sense to feed a freshly installed box with educational
software.

Kind regards

      Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 27 Aug 2014 23:57:04 GMT) (full text, mbox, link).

Message #70 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

On Mittwoch, 27. August 2014, Mike Gabriel wrote:
> I guess this only makes sense if a Debian Edu machine (standalone) can
> be installed via Debian's normal D-I, right?

why? and why limit this to stabalone?


cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Franklin Weng <franklin@goodhorse.idv.tw>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 28 Aug 2014 01:00:05 GMT) (full text, mbox, link).

Message #75 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

2014/8/26 下午7:28 於 "Andreas Tille" <andreas@an3as.eu> 寫道：
>
> Hi,
>
> I think it should be also a criterion that the team behind the Blend
> confirms that they are interested and so I'm hereby pinging all lists in
> question to ask you for confirmation.  I have set Reply-To to the bug
> report and the general Blends list in case you are interested in further
> discussion with other Blends.
>

Debian ezgo blends is active.
(Is that what you meant to reply so that the blends can be kept active?)

Franklin

[Message part 2 (text/html, inline)]

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 28 Aug 2014 06:27:10 GMT) (full text, mbox, link).

Message #80 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Franklin,

On Thu, Aug 28, 2014 at 08:57:37AM +0800, Franklin Weng wrote:
> > I think it should be also a criterion that the team behind the Blend
> > confirms that they are interested and so I'm hereby pinging all lists in
> > question to ask you for confirmation.  I have set Reply-To to the bug
> > report and the general Blends list in case you are interested in further
> > discussion with other Blends.
> >
> 
> Debian ezgo blends is active.
> (Is that what you meant to reply so that the blends can be kept active?)

Ahh, sorry for leaving out EzGo in the list given in my initial bug report.

What I really meant is:

   1. Do you think Blends should be listed by tasksel at installation time.
   2. Do you want to be Debian EzGo added to this list.

Kind regards

     Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Steven Chamberlain <steven@pyro.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 28 Aug 2014 12:09:04 GMT) (full text, mbox, link).

Message #85 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 28/08/14 00:53, Holger Levsen wrote:
> On Mittwoch, 27. August 2014, Mike Gabriel wrote:
>> I guess this only makes sense if a Debian Edu machine (standalone) can
>> be installed via Debian's normal D-I, right?
> 
> why? and why limit this to stabalone?

Do the regular Debian Edu installers do some special configuration
before the tasksel stage?  Might this be too late in the installer to
correctly install at least some of the machine types?

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[signature.asc (application/pgp-signature, attachment)]

Message #90 received at 758116@bugs.debian.org (full text, mbox, reply):

On 14/08/14 12:26, Andreas Tille wrote:
> IMHO it would do a nice service to our users to promote these topics on
> our installers at the time when tasks will be selected.

I think this is brilliant.  It puts much-deserved attention on the
blends, and allows to deliver the Debian 'product' in ways that better
fit with realised use cases.

The featured blends could give their product away much more easily:  it
would just be a regular Debian install disc.  (Perhaps allow the
bootloader to pass in a 'default blend' parameter - for someone who
customises the disc's artwork / physical packaging to their blend - but
still keep the others listed in the installer to cross-promote them.)

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #95 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Andreas,


2014-08-28 14:23 GMT+08:00 Andreas Tille <andreas@an3as.eu>:

> Hi Franklin,
>
> On Thu, Aug 28, 2014 at 08:57:37AM +0800, Franklin Weng wrote:
> > > I think it should be also a criterion that the team behind the Blend
> > > confirms that they are interested and so I'm hereby pinging all lists
> in
> > > question to ask you for confirmation.  I have set Reply-To to the bug
> > > report and the general Blends list in case you are interested in
> further
> > > discussion with other Blends.
> > >
> >
> > Debian ezgo blends is active.
> > (Is that what you meant to reply so that the blends can be kept active?)
>
> Ahh, sorry for leaving out EzGo in the list given in my initial bug report.
>
> What I really meant is:
>
>    1. Do you think Blends should be listed by tasksel at installation time.
>

Yes


>    2. Do you want to be Debian EzGo added to this list.
>
>
Yes, and that's the original idea when Andrew created Debian ezgo blends.


>  Kind regards
>
>      Andreas.
>
> --
> http://fam-tille.de
>


Thanks,
Franklin

[Message part 2 (text/html, inline)]

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 28 Aug 2014 16:42:08 GMT) (full text, mbox, link).

Message #100 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

[dropping persons from recipients, and adding bug#311188 ]

Quoting Steven Chamberlain (2014-08-28 14:05:22)
> On 28/08/14 00:53, Holger Levsen wrote:
>> On Mittwoch, 27. August 2014, Mike Gabriel wrote:
>>> I guess this only makes sense if a Debian Edu machine (standalone) 
>>> can be installed via Debian's normal D-I, right?
>> 
>> why? and why limit this to stabalone?
>
> Do the regular Debian Edu installers do some special configuration 
> before the tasksel stage?  Might this be too late in the installer to 
> correctly install at least some of the machine types?

The package debian-edu-install ships /etc/init.d/xdebian-edu-firstboot, 
registers debconf question debian-edu-install/run-firstboot, and checks 
for magic file /etc/debian-edu/xdebian-edu-firstboot..

The package debian.edu-config ships a range of CFEngine scripts and 
/usr/share/debian-edu-config/tools/run-at-firstboot.

Above mechanisms stay dormant, however, unless triggered correctly - 
i.e. when "installed on a normal system, nothing (bad) happens"[1]. One 
answer to your question could therefore be a simple "no".

[1] https://bugs.debian.org/bug=311188#217

...another more descriptive, I believe, answer could be "You don't 
really have a Debian Edu system when installing it on a Debian system".

I believe that second elaborated view is the reason for Mike's question.

To me it is far from "perfectly sense" to offer "Debian Edu" in 
debian-installer to get some "educational software" - I would expect to 
get a Debian Edu system.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#758116; Package tasksel. (Sun, 31 Aug 2014 12:03:08 GMT) (full text, mbox, link).

Acknowledgement sent to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sun, 31 Aug 2014 12:03:08 GMT) (full text, mbox, link).

Message #105 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Jonas, hi all,

On  Do 28 Aug 2014 18:39:34 CEST, Jonas Smedegaard wrote:

> ...another more descriptive, I believe, answer could be "You don't
> really have a Debian Edu system when installing it on a Debian system".
>
> I believe that second elaborated view is the reason for Mike's question.
>
> To me it is far from "perfectly sense" to offer "Debian Edu" in
> debian-installer to get some "educational software" - I would expect to
> get a Debian Edu system.
>
>  - Jonas

That's what I was aiming at! Jonas, thanks for reading inbetween my  
lines and verbalizing the unsaid.

:-)

We are currently testing deployment of Debian Edu systems by  
installing vanilla Debian and then pulling in required packages on  
post-installation. The results will come in by the end of next week  
(once I have time for looking at finalizing those installations).

There are packages in debian-edu SVN [1] ("educlient", "eduroaming")  
that have some post-installation logic turning a Debian system into a  
Skolelinux / Debian Edu system, as well. I will probably take a look  
at those, as well, during our test cycle. Originally, they were  
designed to turn Ubuntu systems into Debian Edu client machines AFAIR.  
So let's see.

But still, I guess it is pointless offering a Debian Edu blend in D-I  
if the result after installation won't be a proper Debian Edu  
workstation.

Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#758116; Package tasksel. (Mon, 01 Sep 2014 19:36:20 GMT) (full text, mbox, link).

Acknowledgement sent to Steven Chamberlain <steven@pyro.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Mon, 01 Sep 2014 19:36:20 GMT) (full text, mbox, link).

Message #110 received at 758116@bugs.debian.org (full text, mbox, reply):

On 26/08/14 12:27, Andreas Tille wrote:
> H[...]  Joey Hess raised the question
> about the criteria to add a Blend or not.  I answered "all in the list
> of the bug report #758116" which IMHO fits the criterion of "actively
> maintained and some valuable content for users".

Perhaps a way to decide the ordering of items in the menu - popcon.d.o
can give some relative figures on Blends' install base, but I don't know
if this definitely includes all of them:

> $ curl -s 'http://popcon.debian.org/by_inst' | grep -e '-tasks '
> 10053 education-tasks                  983   355   448   173     7 (Debian Edu Developers)         
> 10929 science-tasks                    830    76   660    58    36 (Debian Science Team)           
> 11000 junior-tasks                     818     0     0     0   818 (Debian Junior)                 
> 15895 plasma-widget-smooth-tasks       370    71   285    14     0 (Salvo Rinaldi)                 
> 17234 gis-tasks                        305     0     0     0   305 (Debian Gis Project)            
> 17279 med-tasks                        304    26   250    11    17 (Debian Med Packaging Team)     
> 21947 multimedia-tasks                 166     0     0     0   166 (Debian Multimedia Maintainers) 
> 32922 games-tasks                       57     0     0     0    57 (Debian Games Team)             
> 34392 debichem-tasks                    50     0     0     0    50 (Debichem Team)                 
> 35076 ezgo-tasks                        47     0     0     0    47 (Debain Ezgo Packaging Team)    
> 41997 tine20-tasks                      27    13    11     1     2 (Not in sid)                    
> 69244 site-tasks                         5     0     0     0     5 (Not in sid)                    
> 93698 agenda-tasks                       1     1     0     0     0 (Not in sid)   

(column 3 is install count among active popcon users;  descending order)

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Acknowledgement sent to Per Andersson <avtobiff@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 03 Sep 2014 05:48:05 GMT) (full text, mbox, link).

Message #115 received at 758116@bugs.debian.org (full text, mbox, reply):

On Mon, Sep 1, 2014 at 9:34 PM, Steven Chamberlain <steven@pyro.eu.org> wrote:
> On 26/08/14 12:27, Andreas Tille wrote:
>> H[...]  Joey Hess raised the question
>> about the criteria to add a Blend or not.  I answered "all in the list
>> of the bug report #758116" which IMHO fits the criterion of "actively
>> maintained and some valuable content for users".
>
> Perhaps a way to decide the ordering of items in the menu - popcon.d.o
> can give some relative figures on Blends' install base, but I don't know
> if this definitely includes all of them:

I don't think this is a particularly good measure since the blends are
relatively unknown.


>> $ curl -s 'http://popcon.debian.org/by_inst' | grep -e '-tasks '
>> 10053 education-tasks                  983   355   448   173     7 (Debian Edu Developers)
>> 10929 science-tasks                    830    76   660    58    36 (Debian Science Team)
>> 11000 junior-tasks                     818     0     0     0   818 (Debian Junior)
>> 15895 plasma-widget-smooth-tasks       370    71   285    14     0 (Salvo Rinaldi)
>> 17234 gis-tasks                        305     0     0     0   305 (Debian Gis Project)
>> 17279 med-tasks                        304    26   250    11    17 (Debian Med Packaging Team)
>> 21947 multimedia-tasks                 166     0     0     0   166 (Debian Multimedia Maintainers)
>> 32922 games-tasks                       57     0     0     0    57 (Debian Games Team)
>> 34392 debichem-tasks                    50     0     0     0    50 (Debichem Team)
>> 35076 ezgo-tasks                        47     0     0     0    47 (Debain Ezgo Packaging Team)
>> 41997 tine20-tasks                      27    13    11     1     2 (Not in sid)
>> 69244 site-tasks                         5     0     0     0     5 (Not in sid)
>> 93698 agenda-tasks                       1     1     0     0     0 (Not in sid)
>
> (column 3 is install count among active popcon users;  descending order)

It would also only rate Science, Edu, and Med (in that order) which might be
good top candidates anyway, but other blends have zero (0) installations
among active popcon users. So in any case, some ordering except popcon
install count is necessary.

I suppose questions regarding ordering can be: 1) What do we think Debian
users want to install? 2) Are there any blends in particular good shape?


--
Per


> Regards,
> --
> Steven Chamberlain
> steven@pyro.eu.org
>
>
> --
> To UNSUBSCRIBE, email to debian-blends-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: https://lists.debian.org/5404CA5C.4030102@pyro.eu.org
>

Message #120 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi,

On Wed, Sep 03, 2014 at 07:45:12AM +0200, Per Andersson wrote:
> 
> I don't think this is a particularly good measure since the blends are
> relatively unknown.

I think it is not a measure for a sequence but rather a measure whether
a Blend should be included or not.  For instance I missed
multimedia-tasks in my list (for the simple reason that I have not seen
any relevant commit since nearly one year).  But for sure multimedia is
quite important for our users and perhaps the fact that there is a
chance to prominently be shown in the installer might be a motivation
for multimedia maintainers to review the tasks (both team members who
previously commited to Git in CC).

> >> $ curl -s 'http://popcon.debian.org/by_inst' | grep -e '-tasks '
> >> 10053 education-tasks                  983   355   448   173     7 (Debian Edu Developers)
> >> 10929 science-tasks                    830    76   660    58    36 (Debian Science Team)
> >> 11000 junior-tasks                     818     0     0     0   818 (Debian Junior)
> >> 15895 plasma-widget-smooth-tasks       370    71   285    14     0 (Salvo Rinaldi)
> >> 17234 gis-tasks                        305     0     0     0   305 (Debian Gis Project)
> >> 17279 med-tasks                        304    26   250    11    17 (Debian Med Packaging Team)
> >> 21947 multimedia-tasks                 166     0     0     0   166 (Debian Multimedia Maintainers)
> >> 32922 games-tasks                       57     0     0     0    57 (Debian Games Team)
> >> 34392 debichem-tasks                    50     0     0     0    50 (Debichem Team)
> >> 35076 ezgo-tasks                        47     0     0     0    47 (Debain Ezgo Packaging Team)
> >> 41997 tine20-tasks                      27    13    11     1     2 (Not in sid)
> >> 69244 site-tasks                         5     0     0     0     5 (Not in sid)
> >> 93698 agenda-tasks                       1     1     0     0     0 (Not in sid)
> >
> > (column 3 is install count among active popcon users;  descending order)
> 
> It would also only rate Science, Edu, and Med (in that order) which might be
> good top candidates anyway, but other blends have zero (0) installations
> among active popcon users. So in any case, some ordering except popcon
> install count is necessary.

I'd consider alphabetic ordering as sensible enough.  I would not
(mis)use popcon stats as ordering criterion in this case.

> I suppose questions regarding ordering can be: 1) What do we think Debian
> users want to install? 2) Are there any blends in particular good shape?

I think both criterions are not as objective as alphabetic order.  Think of
our language selection menu?  Should we try to rank it according to the user
base of a certain language or the translation status?  I think this gets a
clear "no".

Kind regards

         Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Per Andersson <avtobiff@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 03 Sep 2014 12:51:10 GMT) (full text, mbox, link).

Message #125 received at 758116@bugs.debian.org (full text, mbox, reply):

On Wed, Sep 3, 2014 at 8:40 AM, Andreas Tille <andreas@an3as.eu> wrote:
> Hi,
>
> On Wed, Sep 03, 2014 at 07:45:12AM +0200, Per Andersson wrote:
>>
>> I don't think this is a particularly good measure since the blends are
>> relatively unknown.
>
> I think it is not a measure for a sequence but rather a measure whether
> a Blend should be included or not.

Possibly, but the fact is that only three blends have more than zero installs.
Better then to have some criterion for inclusion, possibly as simple as
having a $BLEND-tasks package for tasksel.


>  For instance I missed
> multimedia-tasks in my list (for the simple reason that I have not seen
> any relevant commit since nearly one year).  But for sure multimedia is
> quite important for our users and perhaps the fact that there is a
> chance to prominently be shown in the installer might be a motivation
> for multimedia maintainers to review the tasks (both team members who
> previously commited to Git in CC).
>
>> >> $ curl -s 'http://popcon.debian.org/by_inst' | grep -e '-tasks '
>> >> 10053 education-tasks                  983   355   448   173     7 (Debian Edu Developers)
>> >> 10929 science-tasks                    830    76   660    58    36 (Debian Science Team)
>> >> 11000 junior-tasks                     818     0     0     0   818 (Debian Junior)
>> >> 15895 plasma-widget-smooth-tasks       370    71   285    14     0 (Salvo Rinaldi)
>> >> 17234 gis-tasks                        305     0     0     0   305 (Debian Gis Project)
>> >> 17279 med-tasks                        304    26   250    11    17 (Debian Med Packaging Team)
>> >> 21947 multimedia-tasks                 166     0     0     0   166 (Debian Multimedia Maintainers)
>> >> 32922 games-tasks                       57     0     0     0    57 (Debian Games Team)
>> >> 34392 debichem-tasks                    50     0     0     0    50 (Debichem Team)
>> >> 35076 ezgo-tasks                        47     0     0     0    47 (Debain Ezgo Packaging Team)
>> >> 41997 tine20-tasks                      27    13    11     1     2 (Not in sid)
>> >> 69244 site-tasks                         5     0     0     0     5 (Not in sid)
>> >> 93698 agenda-tasks                       1     1     0     0     0 (Not in sid)
>> >
>> > (column 3 is install count among active popcon users;  descending order)
>>
>> It would also only rate Science, Edu, and Med (in that order) which might be
>> good top candidates anyway, but other blends have zero (0) installations
>> among active popcon users. So in any case, some ordering except popcon
>> install count is necessary.
>
> I'd consider alphabetic ordering as sensible enough.  I would not
> (mis)use popcon stats as ordering criterion in this case.
>
>> I suppose questions regarding ordering can be: 1) What do we think Debian
>> users want to install? 2) Are there any blends in particular good shape?
>
> I think both criterions are not as objective as alphabetic order.  Think of
> our language selection menu?  Should we try to rank it according to the user
> base of a certain language or the translation status?  I think this gets a
> clear "no".

Very good point. I agree with this of course.


--
Per


> Kind regards
>
>          Andreas.
>
> --
> http://fam-tille.de
>
>
> --
> To UNSUBSCRIBE, email to debian-blends-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: https://lists.debian.org/20140903064011.GE23628@an3as.eu
>

Message #130 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Per,

On Wed, Sep 03, 2014 at 02:50:19PM +0200, Per Andersson wrote:
> >
> > I think it is not a measure for a sequence but rather a measure whether
> > a Blend should be included or not.
> 
> Possibly, but the fact is that only three blends have more than zero installs.
> Better then to have some criterion for inclusion, possibly as simple as
> having a $BLEND-tasks package for tasksel.

Ahhh, I see you are refering to the third data column (vote).  Well, I
think popcon simply is failing for metapackages.  You usually do not
vote for the tasks package but rather for the installed depedencies,
right?
 
> > chance to prominently be shown in the installer might be a motivation
> > for multimedia maintainers to review the tasks (both team members who
> > previously commited to Git in CC).
> >
> >> >> $ curl -s 'http://popcon.debian.org/by_inst' | grep -e '-tasks '
> >> >> 10053 education-tasks                  983   355   448   173     7 (Debian Edu Developers)
> >> >> 10929 science-tasks                    830    76   660    58    36 (Debian Science Team)
> >> >> 11000 junior-tasks                     818     0     0     0   818 (Debian Junior)
> >> >> 15895 plasma-widget-smooth-tasks       370    71   285    14     0 (Salvo Rinaldi)
> >> >> 17234 gis-tasks                        305     0     0     0   305 (Debian Gis Project)
> >> >> 17279 med-tasks                        304    26   250    11    17 (Debian Med Packaging Team)
> >> >> 21947 multimedia-tasks                 166     0     0     0   166 (Debian Multimedia Maintainers)
> >> >> 32922 games-tasks                       57     0     0     0    57 (Debian Games Team)
> >> >> 34392 debichem-tasks                    50     0     0     0    50 (Debichem Team)
> >> >> 35076 ezgo-tasks                        47     0     0     0    47 (Debain Ezgo Packaging Team)
> >> >> 41997 tine20-tasks                      27    13    11     1     2 (Not in sid)
> >> >> 69244 site-tasks                         5     0     0     0     5 (Not in sid)
> >> >> 93698 agenda-tasks                       1     1     0     0     0 (Not in sid)
> >> >
> >> > (column 3 is install count among active popcon users;  descending order)
> >
> > I think both criterions are not as objective as alphabetic order.  Think of
> > our language selection menu?  Should we try to rank it according to the user
> > base of a certain language or the translation status?  I think this gets a
> > clear "no".
> 
> Very good point. I agree with this of course.

:-)

Kind regards

      Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Felipe Sateler <fsateler@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 03 Sep 2014 13:27:08 GMT) (full text, mbox, link).

Message #135 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi,

On Wed, Sep 3, 2014 at 2:40 AM, Andreas Tille <andreas@an3as.eu> wrote:
> Hi,
>
> On Wed, Sep 03, 2014 at 07:45:12AM +0200, Per Andersson wrote:
>>
>> I don't think this is a particularly good measure since the blends are
>> relatively unknown.
>
> I think it is not a measure for a sequence but rather a measure whether
> a Blend should be included or not.  For instance I missed
> multimedia-tasks in my list (for the simple reason that I have not seen
> any relevant commit since nearly one year).  But for sure multimedia is
> quite important for our users and perhaps the fact that there is a
> chance to prominently be shown in the installer might be a motivation
> for multimedia maintainers to review the tasks (both team members who
> previously commited to Git in CC).

Sorry for not commenting on the bug but we did start a discussion
within the multimedia team on wether we want to pursue this or not.
Unfortunately, there seems to not be enough manpower to actually
prepare a reasonable set of tasks. We did discuss what would be
desirable, but nobody actually stepped up and offered to do the job.

I would very much like to have the multimedia tasks included, but
unfortunately I think they are not high quality enough at the moment,
and I can't commit to improving them in the short term (ie, before the
freeze).

-- 

Saludos,
Felipe Sateler

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Mon, 08 Sep 2014 03:21:04 GMT) (full text, mbox, link).

Message #140 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

There is going to be a limited amount of space in tasksel for blends,
given current debconf UI constraints.

I think that using popcon as a rough pass to select the blends makes
rather a lot of sense. The "Debian Pure Blends" effort has been around
for several releases and been publicised. The individual blends have had
time to find users, or not. If there is some new and upcoming blend that
makes sense to promote for a while, it might make sense to disregard the
popcon numbers for a while.

(Of course, you want to read the right column in the popcon output,
in particular the number of installs, not number of metapackages in
use, which tends to be 0.)

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 09 Sep 2014 11:09:04 GMT) (full text, mbox, link).

Message #145 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Cyril,

On Mon, Sep 08, 2014 at 02:33:06AM +0200, Cyril Brulebois wrote:
> 
> At some point it would really be nice to have a summary of what happened
> or what was discussed at DebConf, but on mailing lists. While I'm very
> happy to see stuff happen during in person meetings, keeping people who
> weren't there out of the loop shouldn't happen IMO.

+1
(specifically for people who did not joined DebConf)

> (I'm probably biased since I'm in that category; and maybe additionally
> slightly annoyed since I spent quite some time providing material for
> discussion with no feedback as of yet.)

Regarding one item of Adam's list the Blends topic you might like to
have a look at #758116 where we try to write down opinions.  Please note
that any of these Blends provide a *set* of tasks so it might make sense
if we have the space to add all seven listed Blends on the first screen
and enable to select single tasks after selecting one Blend (and perhaps
selecting more tasks from other Blends like for instance

    Debian Med ---> select Biology
    <go back to main screen>
    Debian Science ---> select tasks Statistics and Viewing

or something like this).

Kind regards and thanks for all your work for d-i

    Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 09 Sep 2014 12:48:04 GMT) (full text, mbox, link).

Message #150 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Thomas,

thanks for caring for this topic.

On Mon, Sep 08, 2014 at 11:15:48PM +0800, Thomas Goirand wrote:
> ...
> So, with what you're proposing, we'll have something like this:
> 
>    │    [*] Desktop environment                             │
>    │    [*] ... Xfce                                        │
>    │    [ ] ... GNOME                                       │
>    │    [ ] ... KDE                                         │
>    │    [ ] Debian pure blends                              │
>    │    [ ] ... Debian Edu                                  │
>    │    [ ] ... Debian Med                                  │
                  [ ] ... Biology
                  [ ] ... Medical imaging
                  [ ] ... Medical practice
                  ...
>    │    [ ] ... DebiChem                                    │
                  [ ] ... Ab inito
                  [ ] ... Crystallography
                  [ ] ... Molecular modelling
                  ...
>    │    [ ] Openstack                                       │
>    │    [ ] ... Compute Node                                │
>    │    [ ] ... Proxy Node                                  │
> 
> This looks awesome already, a way better than what we had before.

+1

With the additional hint that Blends consists of a set of tasks which
usually can selected separately and in several (if not most) practical
cases it does not make sense to install them all at once.

Kind regards

       Andreas.

> [1] https://lists.debian.org/debian-boot/2014/09/msg00206.html
> [2] https://wiki.debian.org/tasksel/MoreTasks

-- 
http://fam-tille.de

Message #155 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Cyril,

On Sun, Oct 05, 2014 at 09:11:24PM +0200, Cyril Brulebois wrote:
> The Debian Installer team[1] is pleased to announce the second beta
> release of the installer for Debian 8 "Jessie".
> ...

thanks for your report and your continuous work on the installer.

I wonder what might be the opinion of the installer team about bug
#758116 which contains the suggestion to add Blends to the tasks
selection menu and whether we could do something to help with the
implementation.  The bug report received a lot of agreement from people
working in different Blends but only one question[1] of Joey Hess
probably wearing his tasksel maintainer hat.  For me it is not clear
whether this is an issue of deciding what Blend to include (Joey's
question was targeting into this direction) or whether you hesitate to
implement this at all.  Since it is not clear whether you think this
kind of menu is sensible or not we did not yet mindet providing patches
or so to support your work.  Some kind of statement could be motivating
to provide more work on the technical side.

Kind regards and thanks again for your work on the installer

     Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#140

-- 
http://fam-tille.de

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 14 Oct 2014 04:03:04 GMT) (full text, mbox, link).

Message #160 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Andreas,

Andreas Tille <andreas@an3as.eu> (2014-10-08):
> On Sun, Oct 05, 2014 at 09:11:24PM +0200, Cyril Brulebois wrote:
> > The Debian Installer team[1] is pleased to announce the second beta
> > release of the installer for Debian 8 "Jessie".
> > ...
>  
> thanks for your report and your continuous work on the installer.
> 
> I wonder what might be the opinion of the installer team about bug
> #758116 which contains the suggestion to add Blends to the tasks
> selection menu and whether we could do something to help with the
> implementation.  The bug report received a lot of agreement from people
> working in different Blends but only one question[1] of Joey Hess
> probably wearing his tasksel maintainer hat.  For me it is not clear
> whether this is an issue of deciding what Blend to include (Joey's
> question was targeting into this direction) or whether you hesitate to
> implement this at all.  Since it is not clear whether you think this
> kind of menu is sensible or not we did not yet mindet providing patches
> or so to support your work.  Some kind of statement could be motivating
> to provide more work on the technical side.
> 
> Kind regards and thanks again for your work on the installer
> 
>      Andreas.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#140

well to be honest the whole blend story came as a surprise.

I think we identified quite early in the release cycle that we would
need to finally do something about the desktop situation (which first
landed in D-I Jessie Beta 2).

Blends were first mentioned during a DC'14 talk in late August. At the
moment my personal feeling about this is that it looks a bit late, and
I'm almost certainly not going to drive such changes myself. I don't
have any strong incentive to prevent other people from working on this
though. (Of course, any work should happen sooner than later.)

Of course, if blends support ends up not being merged for Jessie, I'm
very sorry for people having participated in the discussion and their
false hope. :(

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 14 Oct 2014 08:03:04 GMT) (full text, mbox, link).

Message #165 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Cyril,

On Tue, Oct 14, 2014 at 06:02:11AM +0200, Cyril Brulebois wrote:
> Hi Andreas,
> 
> Andreas Tille <andreas@an3as.eu> (2014-10-08):
> > On Sun, Oct 05, 2014 at 09:11:24PM +0200, Cyril Brulebois wrote:
> > > The Debian Installer team[1] is pleased to announce the second beta
> > > release of the installer for Debian 8 "Jessie".
> > > ...
> >  
> > thanks for your report and your continuous work on the installer.
> > 
> > I wonder what might be the opinion of the installer team about bug
> > #758116 which contains the suggestion to add Blends to the tasks
> > selection menu and whether we could do something to help with the
> > implementation.  The bug report received a lot of agreement from people
> > working in different Blends but only one question[1] of Joey Hess
> > probably wearing his tasksel maintainer hat.  For me it is not clear
> > whether this is an issue of deciding what Blend to include (Joey's
> > question was targeting into this direction) or whether you hesitate to
> > implement this at all.  Since it is not clear whether you think this
> > kind of menu is sensible or not we did not yet mindet providing patches
> > or so to support your work.  Some kind of statement could be motivating
> > to provide more work on the technical side.
> > 
> > Kind regards and thanks again for your work on the installer
> > 
> >      Andreas.
> > 
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#140
> 
> well to be honest the whole blend story came as a surprise.

Ahhh, this in turn is surprising for me since the first "version" of
this bug is dated 24 Mar 2003 (#186085) :-).  But I agree that Blends
are not widely known even if I was proactively running around since
more than ten years telling people
  "Is there a topic in Debian you care about? Create a Blend today!"
as Asheesh advised me in last years DebConf talk[1 - just see the
linked subtitles text to save time - it is *very* speaking for the
whole topic!]

In other words:  I perfectly know the fact that Blends are widely
ignored even amongst Debian developers and that's not about you / the
debian-boot team - perhaps my "running around and tell people" is just
not the right way to convince people.  At least I can tell that those
people who were listening started to like the idea [see 1].

> I think we identified quite early in the release cycle that we would
> need to finally do something about the desktop situation (which first
> landed in D-I Jessie Beta 2).

Well, Blends and "the desktop situation" could be considered orthogonal.
The main goal of a Blend is not primarily to tweak the desktop (even if
this could be done).  It is rather about the applications.  In Debian
Med we even have a cluster task which contains exclusively those
packages which can be run without a graphical desktop (bio-cloud [2]).

> Blends were first mentioned during a DC'14 talk in late August.

To be precise:  Blends (formerly Custom Debian Distributions - yes, I'm
*not* responsible for this broken name :-() was mentioned on *any*
DebConf I joined with exception of DebConf 0 where this idea was not yet
born.  If you scroll down my talks page[3] you stumble upon DebConf 1 in
Bordeaux 2001 as first time presenting the idea on a DebConf.  Any of my
talks raised the question, whether there is a menu in the installer to
a) get an easy installation method and b) propagate the Blends concept
(which is obviously needed).  It might have been the fault of people who
care about Blends that they did not approached the Debian Boot team
earlier, yes.  The reason why at least I stayed away from this since
2003 (#186085) was that I have seen little chances to change the
refusal.  However, since recently some Blends of some more general
interest like Debian Games and Debian GIS started or gained some
traktion resp.  the idea came up to rise this question on IRC in the
DebConf talk.

> At the
> moment my personal feeling about this is that it looks a bit late, and
> I'm almost certainly not going to drive such changes myself.

I perfectly agree that you as the one person army keeping Debian Boot
alive (hey, do you like the Blends born idea to prove this point[4]??)
should not spend extra time cycles into the implementation.

> I don't
> have any strong incentive to prevent other people from working on this
> though. (Of course, any work should happen sooner than later.)

That's in fact a quite motivating incentive and I perfectly agree that
we really should start rather yesterday than today.  The thing is that
it is not really clear to me, what we should do rather than adding the
packages

   edu-tasks
   games-tasks
   gis-tasks
   junior-tasks
   med-tasks
   science-tasks
   debichem-tasks
   ezgo-tasks

(multimedia-tasks is not ready according to their maintainer[5]) to the
boot disks.

Joey Hess as tasksel maintainer mentioned "limited amount of space in
tasksel for blends" but this does not give a sensible hint of what exact
action we should do now.  I think currently eight additional lines is
not that much.  I also totally contradict to Joey's statement "The
'Debian Pure Blends' effort has been around for several releases and
been publicised." and I take [1] as sufficient argument that it is not
the case.  Blends were never ever regarded in practice as some Debian
internal thing and *every* time when I talk about Blends on conferences
and in private discussions I will be asked:  "Why don't you do this cool
stuff right into Debian instead of a derivative?"  It would *really*
help in this kind of discussion to point to the Debian installer ...

So if we would get some helping hand what exactly technically needs to
be done, we could try to come up with some solution.

> Of course, if blends support ends up not being merged for Jessie, I'm
> very sorry for people having participated in the discussion and their
> false hope. :(

Well, after more than ten years work on this the time of "false hope" is
over. ;-)  I'm really happy about the "no incentive to prevent other
people from working on this".  Perhaps some slight hint - perhaps even
from Joey - would help to get this done.

Kind regards

       Andreas.

[1] http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/987_How_to_attract_new_developers_for_your_team.ogv
    ... or instead of spending time into the full video you rather might
    like to simply browse the subtitles starting at line 2379
    http://anonscm.debian.org/cgit/debconfsubs/debconfsubs.git/tree/2013/DebConf13/english/987_How_to_attract_new_developers_for_your_team.en.srt
[2] http://blends.debian.org/med/tasks/cloud
[3] https://people.debian.org/~tille/talks/
[4] http://blends.debian.net/liststats/authorstat_debian-boot.png
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#135

-- 
http://fam-tille.de

Message #170 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi again Andreas,

Andreas Tille <tille@debian.org> (2014-10-14):
> On Tue, Oct 14, 2014 at 06:02:11AM +0200, Cyril Brulebois wrote:
> > well to be honest the whole blend story came as a surprise.
> 
> Ahhh, this in turn is surprising for me since the first "version" of
> this bug is dated 24 Mar 2003 (#186085) :-).  But I agree that Blends
> are not widely known even if I was proactively running around since
> more than ten years telling people
>   "Is there a topic in Debian you care about? Create a Blend today!"
> as Asheesh advised me in last years DebConf talk[1 - just see the
> linked subtitles text to save time - it is *very* speaking for the
> whole topic!]
> 
> In other words:  I perfectly know the fact that Blends are widely
> ignored even amongst Debian developers and that's not about you / the
> debian-boot team - perhaps my "running around and tell people" is just
> not the right way to convince people.  At least I can tell that those
> people who were listening started to like the idea [see 1].

to clarify a bit: my surprise was about blends support in tasksel/d-i.
I've known about blends for a while but I don't think that topic popped
up in my debian-boot radar during the whole Jessie release cycle.

> > I think we identified quite early in the release cycle that we would
> > need to finally do something about the desktop situation (which first
> > landed in D-I Jessie Beta 2).
> 
> Well, Blends and "the desktop situation" could be considered orthogonal.
> The main goal of a Blend is not primarily to tweak the desktop (even if
> this could be done).  It is rather about the applications.  In Debian
> Med we even have a cluster task which contains exclusively those
> packages which can be run without a graphical desktop (bio-cloud [2]).

I meant the needed changes in tasksel to support both desktop selection
and blends.

> > Blends were first mentioned during a DC'14 talk in late August.
> 
> To be precise:  Blends (formerly Custom Debian Distributions - yes, I'm
> *not* responsible for this broken name :-() was mentioned on *any*
> DebConf I joined with exception of DebConf 0 where this idea was not yet
> born.  If you scroll down my talks page[3] you stumble upon DebConf 1 in
> Bordeaux 2001 as first time presenting the idea on a DebConf.  Any of my
> talks raised the question, whether there is a menu in the installer to
> a) get an easy installation method and b) propagate the Blends concept
> (which is obviously needed).  It might have been the fault of people who
> care about Blends that they did not approached the Debian Boot team
> earlier, yes.  The reason why at least I stayed away from this since
> 2003 (#186085) was that I have seen little chances to change the
> refusal.  However, since recently some Blends of some more general
> interest like Debian Games and Debian GIS started or gained some
> traktion resp.  the idea came up to rise this question on IRC in the
> DebConf talk.

Blends… support in d-i (during this release cycle) was what I meant,
sorry for being unclear. Hopefully that was covered by the above
clarification. ;)

> > At the moment my personal feeling about this is that it looks a bit
> > late, and I'm almost certainly not going to drive such changes
> > myself.
> 
> I perfectly agree that you as the one person army keeping Debian Boot
> alive (hey, do you like the Blends born idea to prove this point[4]??)
> should not spend extra time cycles into the implementation.

That really isn't true, there are many other developers, reporters, and
patch providers. I'm only adding glue or oil where needed… Of course we
could do with more hands (look at the BTS), but I'm far for being the
only one working on d-i.

> > I don't have any strong incentive to prevent other people from
> > working on this though. (Of course, any work should happen sooner
> > than later.)
> 
> That's in fact a quite motivating incentive and I perfectly agree that
> we really should start rather yesterday than today.  The thing is that
> it is not really clear to me, what we should do rather than adding the
> packages
> 
>    edu-tasks
>    games-tasks
>    gis-tasks
>    junior-tasks
>    med-tasks
>    science-tasks
>    debichem-tasks
>    ezgo-tasks
> 
> (multimedia-tasks is not ready according to their maintainer[5]) to the
> boot disks.
> 
> Joey Hess as tasksel maintainer mentioned "limited amount of space in
> tasksel for blends" but this does not give a sensible hint of what exact
> action we should do now.  I think currently eight additional lines is
> not that much.  I also totally contradict to Joey's statement "The
> 'Debian Pure Blends' effort has been around for several releases and
> been publicised." and I take [1] as sufficient argument that it is not
> the case.  Blends were never ever regarded in practice as some Debian
> internal thing and *every* time when I talk about Blends on conferences
> and in private discussions I will be asked:  "Why don't you do this cool
> stuff right into Debian instead of a derivative?"  It would *really*
> help in this kind of discussion to point to the Debian installer ...
> 
> So if we would get some helping hand what exactly technically needs to
> be done, we could try to come up with some solution.

I'm not sure we have 8 slots at the moment. I'm pretty sure a scrollbar
(if at all feasible) in a multi-choice menu would be a bad idea. Maybe
we'd need a separate prompt for blends. Joey will likely be able to tell
you more about this.

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 14 Oct 2014 09:21:22 GMT) (full text, mbox, link).

Message #175 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Cyril,

On Tue, Oct 14, 2014 at 10:14:53AM +0200, Cyril Brulebois wrote:
> > 
> > In other words:  I perfectly know the fact that Blends are widely
> > ignored even amongst Debian developers and that's not about you / the
> > debian-boot team - perhaps my "running around and tell people" is just
> > not the right way to convince people.  At least I can tell that those
> > people who were listening started to like the idea [see 1].
> 
> to clarify a bit: my surprise was about blends support in tasksel/d-i.
> I've known about blends for a while but I don't think that topic popped
> up in my debian-boot radar during the whole Jessie release cycle.

I admit I expected *you* to know about Blends for a while - but
considering the video recorded quote I think I was not wrong using this
chance to point this out for other readers of this mail as it is really
a fact that I always meet DDs who mix up this concept with derivatives.
 
> > Well, Blends and "the desktop situation" could be considered orthogonal.
> > The main goal of a Blend is not primarily to tweak the desktop (even if
> > this could be done).  It is rather about the applications.  In Debian
> > Med we even have a cluster task which contains exclusively those
> > packages which can be run without a graphical desktop (bio-cloud [2]).
> 
> I meant the needed changes in tasksel to support both desktop selection
> and blends.

OK.

> > ...
> > earlier, yes.  The reason why at least I stayed away from this since
> > 2003 (#186085) was that I have seen little chances to change the
> > refusal.  However, since recently some Blends of some more general
> > interest like Debian Games and Debian GIS started or gained some
> > traktion resp.  the idea came up to rise this question on IRC in the
> > DebConf talk.
> 
> Blends… support in d-i (during this release cycle) was what I meant,
> sorry for being unclear. Hopefully that was covered by the above
> clarification. ;)

Yes it was. :-)  However, I also had taken the chance to refer to an
earlier bug (perhaps also to review its old arguments).
 
> > I perfectly agree that you as the one person army keeping Debian Boot
> > alive (hey, do you like the Blends born idea to prove this point[4]??)
> > should not spend extra time cycles into the implementation.
> 
> That really isn't true, there are many other developers, reporters, and
> patch providers. I'm only adding glue or oil where needed… Of course we
> could do with more hands (look at the BTS), but I'm far for being the
> only one working on d-i.

I agree that my term was a bit in terms of a compliment in the sense of
a "friendly lie".  I was not trying to underestimate the work of those
people who are providing smaller contributions.  However, you really
find lots of graphs similar like[4] which show the feature of one
dominant person at a certain time.  Perhaps you take this as:  Thanks
for the effort you spent obviously for debian-boot.

> > That's in fact a quite motivating incentive and I perfectly agree that
> > we really should start rather yesterday than today.  The thing is that
> > it is not really clear to me, what we should do rather than adding the
> > packages
> > 
> >    edu-tasks
> >    games-tasks
> >    gis-tasks
> >    junior-tasks
> >    med-tasks
> >    science-tasks
> >    debichem-tasks
> >    ezgo-tasks
> > 
> > (multimedia-tasks is not ready according to their maintainer[5]) to the
> > boot disks.
> > 
> > Joey Hess as tasksel maintainer mentioned "limited amount of space in
> > tasksel for blends" but this does not give a sensible hint of what exact
> > action we should do now.  I think currently eight additional lines is
> > not that much.  I also totally contradict to Joey's statement "The
> > 'Debian Pure Blends' effort has been around for several releases and
> > been publicised." and I take [1] as sufficient argument that it is not
> > the case.  Blends were never ever regarded in practice as some Debian
> > internal thing and *every* time when I talk about Blends on conferences
> > and in private discussions I will be asked:  "Why don't you do this cool
> > stuff right into Debian instead of a derivative?"  It would *really*
> > help in this kind of discussion to point to the Debian installer ...
> > 
> > So if we would get some helping hand what exactly technically needs to
> > be done, we could try to come up with some solution.
> 
> I'm not sure we have 8 slots at the moment. I'm pretty sure a scrollbar
> (if at all feasible) in a multi-choice menu would be a bad idea.

I agree here.  However, I think it would be a shame to drop a good idea
(and as far as I understood the responses to the bug it is considered
good by several people) since we failed to find a sensible menu design.

> Maybe we'd need a separate prompt for blends.

I perfectly agree that some additional menu level would be the most
natural way in my eyes.  I think I mentioned this before. Hmmm, just
wondering why I can't find this term in the previous bugreport(s) since
I always imagined this.  May be there is no instance of this since there
never was a real discussion whether we should do it at all and thus
implementation details were not discussed at all.

> Joey will likely be able to tell
> you more about this.

I'm keen in hearing this. :-)

Kind regards

       Andreas.

[4] http://blends.debian.net/liststats/authorstat_debian-boot.png

-- 
http://fam-tille.de

Message #180 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Bas,

On Tue, Oct 14, 2014 at 07:19:36PM +0200, Bas Wijnen wrote:
> On Tue, Oct 14, 2014 at 11:20:02AM +0200, Andreas Tille wrote:
> > I admit I expected *you* to know about Blends for a while - but
> > considering the video recorded quote I think I was not wrong using this
> > chance to point this out for other readers of this mail as it is really
> > a fact that I always meet DDs who mix up this concept with derivatives.
> 
> I have heard about them for quite a while, indeed, but I must say that I
> never entirely understood what they are. I'm guessing I'm not alone in
> this.

You belong to a majority if I might conclude from my experience.  I have
no idea whether I should feel responsible for this but I'm fighting on
several fronts like the extensive documentation[1] and countless
talks[2] as well as trying to push newcomers into the topic by
sponsering their packages[3].

> So let me write what I think they are, and then you can correct
> me.  I've read the explanation on the wiki, but I'm still not sure if I
> understand it right.
> 
> I think a blend is a system you can install, which after installing is a
> regular Debian system, set up for a particular task.  Because it's a
> regualr Debian system, after installation packages can be installed and
> removed just like on any other Debian system, and any other system can
> be turned into a blend by installing the right packages.

For the moment the way to install Blends is to use the plain Debian
installer and afterwards install a bunch of metapackages.  There is one
exception Debian Edu / Skolelinux which uses dedicated installation
medias with pre-feeded debconf data.  There is a long standing
discussion whether Debian Edu deserves the term "pure" but I will not
dive into this can of worms since I do not want to spoil the general
picture here with details caused by a single bug (Debian Edu people will
know it by heart).  The lack of a missing installer for all other Blends
is a frequently criticised problem and I personally think this should be
fixed by the integration into the official boot cds since this fits to
the nature of Blends which are a subset of Debian.

I'd like to add some informal ideas about Blends to perhaps give a
better picture of the idea:

  - Several people entertain deriving from Debian and actually the never
    ending misconception about Blends is that they are derivatives.  But
    Blends are derivatives "done the right way" - by not deriving Debian
    and rather do the adaptations inside Debian.  The goal is to save
    time and prevent reinventing the wheel on the (non)derivers side and
    to bundle forces right into Debian.
  - Blends are a way to advertise Debian in specific fields of interest
    I personally started from a point where I wanted to reach a status,
    that if somebody wonders what distribution to use for biology and
    medical care the natural answer should be "Use Debian"  We could
    easily reach this goal for other fields of interest if all our
    dedicated experts we had in Debian would work on this direction in
    their own field.
  - Blends is also about forming teams inside Debian to care for a
    certain topic to serve as glue between upstream and the end user and
    if you have watched[4] (as advised in my last mail) you not only get
    an idea about how we form teams but about the Blends concept in
    general.

> From the wiki, it seems that is just the "Pure Blend", because other
> Blends may have extra apt sources.

There might be additional apt sources but it is not only about apt
sources.  For instance (as far as I'm informed) all packages in Debian
Edu are inside Debian and there was just a need to change some
configuration change of some *other* packages which conflicts with
Debian policy (I'm pretty sure Jonas will respond in detail to this mail
- so I save my time here B-)).  The whole pure / non-pure discussion is
from my personal point of view a consequence of nitpicking about policy
compliance which was born out of the problem that some package
maintainers are not willing to accept some more flexible debconf
configuration options.  I agree that policy is something to be really
picky about and will not argue against this but on the other hand it
spoils a bit the simplicy to understand the whole concept.  So a "Debian
Pure Blend" (I use the shortcut "Blend" as a synonym) is fully
integrated into Debian while "non-pure" Blends are trying to approach
the full Debian integration but some minor pieces like a hand full of
packages or some policy conflicting stuff remain on their todo list.

> Is this a good summary?

I hope I added some more points to this summary.

> If so, I think it would be a very good idea to make this part of the
> installer.  And turn the default system into "just another blend".

Sounds like a nice view on the Blends concept. :-)

> Regardless of whether my summary is good, I think the documentation can
> use some improvement.

+1
That's always needed.

> Examples of the target audience would be useful.

Hmmmm.  I had thought / hoped that this is documented in[5].
Enhancements / patches(source is in package source of blends source
package) are always welcome.

> What is made possible or easier with blends?

Installation of a set of packages needed for a specific field of
interest.  Providing an overview for newcomers about all packages of a
specific field of interests.  Here are examples for gamers (task list of
Debian Games [6]) and for scientists (task list of Debian Science [7])
I'm working surrounded by biologists and epidemiologists and I'm just
pointing my (non-Linux using!) colleagues frequently to the according
tasks pages ([8] resp. [9]) of Debian Med to show them what they are
missing by not using Debian.

It would be great to add to these tasks pages the hint that you simply
can click on the according task on the plain Debian installer to get all
these packages installed (even if everybody could install the tasks
manually later also easily).

> What is often confused
> with it, but isn't actually related?

Derivatives are confused all the times (which is one problem of the
previous name which was "Custom Debian Distributions" ... if I only had
vetoed against this term from the first moment :-()

> I admit I didn't spend a lot of
> time trying to find answers to these questions, but I think it shouldn't
> require a large time investment.

Do you think I should add these answers to the Wiki page with the
relevant links?

> > > > Well, Blends and "the desktop situation" could be considered orthogonal.
> 
> Do all blends work well with all desktop environments?  I can see how
> some blends would focus to make things work perfectly with one of them
> only.  In such a case, it makes sense to omit the desktop selection
> after such a blend is selected, or at least let the blend define the
> default.

As far as I know Debian Edu installs KDE and Ezgo also installs
task-kde-desktop.  I'm not aware that any other Blend would prefer any
desktop environment.  I personally do not see the definition of a
specific desktop as primary goal of a Blend.  These both Blends decided
that for their primary goal education KDE would fit better than others
which I have no opinion on since I'm neither in education nor do I use
KDE.

Hope this additional explanation helps

       Andreas.

[1] http://blends.debian.org/blends/
[2] http://people.debian.org/~tille/talks/
[3] http://wiki.debian.org/DebianPureBlends/SoB
[4] http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/987_How_to_attract_new_developers_for_your_team.ogv
    ... or instead of spending time into the full video you rather might
    like to simply browse the subtitles starting at line 2379
    http://anonscm.debian.org/cgit/debconfsubs/debconfsubs.git/tree/2013/DebConf13/english/987_How_to_attract_new_developers_for_your_team.en.srt
[5] http://blends.debian.org/blends/ch04.html
[6] http://blends.debian.org/games/tasks/
[7] http://blends.debian.org/science/tasks/
[8] http://blends.debian.org/med/tasks/bio
[9] http://blends.debian.org/med/tasks/epi

-- 
http://fam-tille.de

Acknowledgement sent to Bas Wijnen <wijnen@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 15 Oct 2014 17:51:15 GMT) (full text, mbox, link).

Message #185 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

On Wed, Oct 15, 2014 at 09:31:36AM +0200, Andreas Tille wrote:
> You belong to a majority if I might conclude from my experience.  I have
> no idea whether I should feel responsible for this but I'm fighting on
> several fronts like the extensive documentation[1] and countless
> talks[2] as well as trying to push newcomers into the topic by
> sponsering their packages[3].

Yes, I noticed.  Thanks for all that work!

> For the moment the way to install Blends is to use the plain Debian
> installer and afterwards install a bunch of metapackages.

Ah, and that's what you want to change now.  That sounds like a very
good idea.

> The lack of a missing installer for all other Blends is a frequently
> criticised problem and I personally think this should be fixed by the
> integration into the official boot cds since this fits to the nature
> of Blends which are a subset of Debian.

Yes, I agree.  For the documentation, I think the main thing that is
missing is "how to start and stop"; important for every documentation.
"Stopping" isn't really relevant in this case (but it doesn't hurt to
mention that the metapackage can be uninstalled).  But "To use a Blend,
you need to install its metapackage" would have clarified it for me.
Once it is possible, it would be very nice if "there is an option to do
this during system install" could be added to that.

>   - Blends are a way to advertise Debian in specific fields of interest
>     I personally started from a point where I wanted to reach a status,
>     that if somebody wonders what distribution to use for biology and
>     medical care the natural answer should be "Use Debian"  We could
>     easily reach this goal for other fields of interest if all our
>     dedicated experts we had in Debian would work on this direction in
>     their own field.

On occasion, I've needed a single-use system; something that boots up
into an application and that shuts down when that application exits.
(Having the full power of Debian in the background is a nice feature,
but mostly unused.)  For example, for dancing rehearsal I want the
instructors to be able to switch their computer on and have the sound
program start up without any interaction.  It isn't hard to set this up,
but if I want to tell other dancing instructors how to do this, it
requires more steps than I would like.  I've tried making custom live
CDs, with a special package that does these things.

Would this use case also be a reason for creating a personal blend?  Or
even an official one?  What would be the easiest way for people to
install a non-official blend?  Should I create my own installer?  Should
the installer be changed to allow entering a URL (for an external apt
source) before it presents the list of available blends?  (I think this
might be a good idea, but it shouldn't be in there by default; only when
the user selects "back" on the blend selection menu.  Or perhaps there
can be a button in that menu for opening the dialog, but if it's for
adding any apt repository, the blends dialog is not the right place for
it.)

> There might be additional apt sources but it is not only about apt
> sources.  For instance (as far as I'm informed) all packages in Debian
> Edu are inside Debian and there was just a need to change some
> configuration change of some *other* packages which conflicts with
> Debian policy (I'm pretty sure Jonas will respond in detail to this mail
> - so I save my time here B-)).

So it installs a package which changes configuration of other packages
when it is installed?  That sounds very ugly...  Isn't there a better
way to preconfigure a system?

> I hope I added some more points to this summary.

Yes, thank you.

> > Examples of the target audience would be useful.
> 
> Hmmmm.  I had thought / hoped that this is documented in[5].

It is, but I think it's too much text and too far away.  It's good that
it's there, but I think it would be good to have on the first page
people are pointed to (which one is that anyway?  The one in the wiki?)
a one-line explanation that is understandable.  The definition of "Pure
Blend" on https://wiki.debian.org/DebianPureBlends is "a subset of
Debian that is configured to support a particular target group
out-of-the-box."  That does not give me enough information to know if I
should be interested enough to read any further.

Oh, and I have another question; this seems very similar to "tasks"; how
is it different?

> Enhancements / patches(source is in package source of blends source
> package) are always welcome.

I might write a patch, but knowing myself I probably don't get around to
actually do that.

> > I admit I didn't spend a lot of
> > time trying to find answers to these questions, but I think it shouldn't
> > require a large time investment.
> 
> Do you think I should add these answers to the Wiki page with the
> relevant links?

Yes, that would be good.  But it should be as short as possible; less
text is better.  However, currently it is not enough text, I think,
which is of course worse.

> Hope this additional explanation helps

Yes, thanks!
Bas

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 15 Oct 2014 19:39:04 GMT) (full text, mbox, link).

Message #190 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Quoting Bas Wijnen (2014-10-15 19:49:32)
> On occasion, I've needed a single-use system; something that boots up 
> into an application and that shuts down when that application exits. 
> (Having the full power of Debian in the background is a nice feature, 
> but mostly unused.)  For example, for dancing rehearsal I want the 
> instructors to be able to switch their computer on and have the sound 
> program start up without any interaction.  It isn't hard to set this 
> up, but if I want to tell other dancing instructors how to do this, it 
> requires more steps than I would like.  I've tried making custom live 
> CDs, with a special package that does these things.
>
> Would this use case also be a reason for creating a personal blend?  
> Or even an official one?  What would be the easiest way for people to 
> install a non-official blend?  Should I create my own installer?  
> Should the installer be changed to allow entering a URL (for an 
> external apt source) before it presents the list of available blends?  
> (I think this might be a good idea, but it shouldn't be in there by 
> default; only when the user selects "back" on the blend selection 
> menu.  Or perhaps there can be a button in that menu for opening the 
> dialog, but if it's for adding any apt repository, the blends dialog 
> is not the right place for it.)

That sounds like an excellent idea for a Blend!

You raise a bunch of questions on how that idea should be implemented 
and work out in details - but that has is open for you as driver of a 
Blend to figure out.

If you do decide to start create above as a Blend, and would be 
interested in collaborating (with me), please do count me in!  I have 
fumbled with a few ideas in the past that seems to fit perfectly to 
above (e.g. a dead-simple videophone "PhoneHome" dialing a hardcoded 
number, or a party jukebox with a touch keyboard (no avoid spilling 
liquids into a real keyboard, or a gaming box to pacify visiting kids, 
or...).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 16 Oct 2014 06:51:05 GMT) (full text, mbox, link).

Message #195 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Bas,

On Wed, Oct 15, 2014 at 07:49:32PM +0200, Bas Wijnen wrote:
> 
> > For the moment the way to install Blends is to use the plain Debian
> > installer and afterwards install a bunch of metapackages.
> 
> Ah, and that's what you want to change now.  That sounds like a very
> good idea.

:-)
 
> > The lack of a missing installer for all other Blends is a frequently
> > criticised problem and I personally think this should be fixed by the
> > integration into the official boot cds since this fits to the nature
> > of Blends which are a subset of Debian.
> 
> Yes, I agree.  For the documentation, I think the main thing that is
> missing is "how to start and stop"; important for every documentation.
> "Stopping" isn't really relevant in this case (but it doesn't hurt to
> mention that the metapackage can be uninstalled).  But "To use a Blend,
> you need to install its metapackage" would have clarified it for me.
> Once it is possible, it would be very nice if "there is an option to do
> this during system install" could be added to that.

I'll put this on my todo list for 2014-11-05+x.
 
> On occasion, I've needed a single-use system; something that boots up
> into an application and that shuts down when that application exits.
> (Having the full power of Debian in the background is a nice feature,
> but mostly unused.)  For example, for dancing rehearsal I want the
> instructors to be able to switch their computer on and have the sound
> program start up without any interaction.  It isn't hard to set this up,
> but if I want to tell other dancing instructors how to do this, it
> requires more steps than I would like.  I've tried making custom live
> CDs, with a special package that does these things.
> 
> Would this use case also be a reason for creating a personal blend?  Or
> even an official one?

Jonas has answered this question.  I'd like to add that I'm no fan of
"personal" things since you spoil the idea of forming a team around the
idea.  I could perfectly imagine such a Blend and every specific
application is a separate "task" (in the Blends slang).  So you can
assemble those people with the goal to run one dedicated application.

> What would be the easiest way for people to
> install a non-official blend?  Should I create my own installer?  Should
> the installer be changed to allow entering a URL (for an external apt
> source) before it presents the list of available blends?  (I think this
> might be a good idea, but it shouldn't be in there by default; only when
> the user selects "back" on the blend selection menu.  Or perhaps there
> can be a button in that menu for opening the dialog, but if it's for
> adding any apt repository, the blends dialog is not the right place for
> it.)

Well, these are good questions.  They are abit hard to answer in a
situation when we are discussing about how to properly install the
currently existing Blends.
 
> > There might be additional apt sources but it is not only about apt
> > sources.  For instance (as far as I'm informed) all packages in Debian
> > Edu are inside Debian and there was just a need to change some
> > configuration change of some *other* packages which conflicts with
> > Debian policy (I'm pretty sure Jonas will respond in detail to this mail
> > - so I save my time here B-)).
> 
> So it installs a package which changes configuration of other packages
> when it is installed?  That sounds very ugly...  Isn't there a better
> way to preconfigure a system?

Yes.  The better way is to convince the single package maintainers.  The
longish discussion is in bug #311188.
 
> > Hmmmm.  I had thought / hoped that this is documented in[5].
> 
> It is, but I think it's too much text and too far away.  It's good that
> it's there, but I think it would be good to have on the first page
> people are pointed to (which one is that anyway?  The one in the wiki?)
> a one-line explanation that is understandable.  The definition of "Pure
> Blend" on https://wiki.debian.org/DebianPureBlends is "a subset of
> Debian that is configured to support a particular target group
> out-of-the-box."  That does not give me enough information to know if I
> should be interested enough to read any further.

Also todo list for 2014-11-05+x.
 
> Oh, and I have another question; this seems very similar to "tasks"; how
> is it different?

Each Blend creates metapackages and a <blenname>-tasks package to feed
tasksel.  Yes, we are using this term actively.  The difference is more
in the content that the tasks are specific for fields of interest but
the used technique is the same (which is intentional to enable
integration into the installer easily).
 
> > Enhancements / patches(source is in package source of blends source
> > package) are always welcome.
> 
> I might write a patch, but knowing myself I probably don't get around to
> actually do that.

... as always with documentation. :-)  The same applies to me to some
extend (and I'm not proud about this).
 
> > Do you think I should add these answers to the Wiki page with the
> > relevant links?
> 
> Yes, that would be good.  But it should be as short as possible; less
> text is better.  However, currently it is not enough text, I think,
> which is of course worse.

Thanks for the helpful hints.
 
Kind regards

     Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 16 Oct 2014 09:42:19 GMT) (full text, mbox, link).

Message #200 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Quoting Andreas Tille (2014-10-16 08:47:19)
> On Wed, Oct 15, 2014 at 07:49:32PM +0200, Bas Wijnen wrote:
>> On occasion, I've needed a single-use system; something that boots up 
>> into an application and that shuts down when that application exits. 
>> (Having the full power of Debian in the background is a nice feature, 
>> but mostly unused.)  For example, for dancing rehearsal I want the 
>> instructors to be able to switch their computer on and have the sound 
>> program start up without any interaction.  It isn't hard to set this 
>> up, but if I want to tell other dancing instructors how to do this, 
>> it requires more steps than I would like.  I've tried making custom 
>> live CDs, with a special package that does these things.
>> 
>> Would this use case also be a reason for creating a personal blend?  
>> Or even an official one?
>
> Jonas has answered this question.  I'd like to add that I'm no fan of 
> "personal" things since you spoil the idea of forming a team around 
> the idea.  I could perfectly imagine such a Blend and every specific 
> application is a separate "task" (in the Blends slang).  So you can 
> assemble those people with the goal to run one dedicated application.

And I fully agree with Andreas: I assumed you were talking about "Debian 
Blends" as defined at 
https://wiki.debian.org/DebianPureBlends#Terminology and that you 
therefore really a generally reusable Blend (sparked by personal _needs_ 
which I see as a perfectly fine drive for creating a Debian Blend).

I am sorry if I twisted your meaning.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Mon, 03 Nov 2014 13:54:23 GMT) (full text, mbox, link).

Message #205 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi,

On Sun, 7 Sep 2014 Joey Hess wrote:
> There is going to be a limited amount of space in tasksel for blends,
> given current debconf UI constraints.

Yes, we know this.  Does this statement of yours mean

  A) I'm not going to fix this
  B) I'm not going to fix this in Jessie
  C) Please make more constructive suggestions for a user
     interface design

> I think that using popcon as a rough pass to select the blends makes
> rather a lot of sense. The "Debian Pure Blends" effort has been around
> for several releases and been publicised. The individual blends have had
> time to find users, or not. If there is some new and upcoming blend that
> makes sense to promote for a while, it might make sense to disregard the
> popcon numbers for a while.

I would like to repeat that if I ever talked about any Blend every talk
got a flavour of the following question:  How can I *easily* install
Blend X?  Unfortunately I always needed to answer that there is no
*easy* way, but you can do "stuff".  I wonder whether you see a chance
to change this for Jessie?  What you expect from the Blends team to
work on this in case your answer would be yes?

Kind regards and thanks for working on tasksel

       Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to "County Court" <daryl.morton@stats.safali34.arvixevps.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Mon, 24 Aug 2015 13:09:03 GMT) (full text, mbox, link).

Acknowledgement sent to Ole Streicher <olebole@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 04 Nov 2015 09:36:04 GMT) (full text, mbox, link).

Message #215 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi,

I am currently preparing a new Debian Pure Blend (Debian Astro), and I 
am curious about the status of this bug. Is this something that is going 
to be implemented in stretch? And what are currently the main obstacles? 
The last entry was from one year ago -- did anything happen behind the 
courtain?

I would be quite interested to get this done; being visible during the 
installation is one of the motivations in creating a Blend.

Best regards

Ole

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 04 Nov 2015 13:06:04 GMT) (full text, mbox, link).

Message #220 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Ole,

Ole Streicher <olebole@debian.org> (2015-11-04):
> I am currently preparing a new Debian Pure Blend (Debian Astro), and I
> am curious about the status of this bug. Is this something that is
> going to be implemented in stretch? And what are currently the main
> obstacles? The last entry was from one year ago -- did anything happen
> behind the courtain?

I might have missed it, but I don't think anything happened.

> I would be quite interested to get this done; being visible during the
> installation is one of the motivations in creating a Blend.

I can certainly appreciate that. Unfortunately I don't have enough
bandwidth to keep track of or shepherd everything d-i related, and
I can't promise if/when I could look into this, sorry.

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #225 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi all,

On Wed, Nov 04, 2015 at 02:04:41PM +0100, Cyril Brulebois wrote:
> 
> > I would be quite interested to get this done; being visible during the
> > installation is one of the motivations in creating a Blend.
> 
> I can certainly appreciate that.

Thanks for the clear statement which is hopefully motivating.

> Unfortunately I don't have enough
> bandwidth to keep track of or shepherd everything d-i related, and
> I can't promise if/when I could look into this, sorry.

I can perfectly understand your point of view and I'm pretty sure that
you will not wait for any task somebody else will put on you. :-)

So the clear extract of this message is:  We need a volunteer and
IMHO we need this *now*.

I'm convinced that Cyril will be able to give a pointer where to poke
around but I for myself have also a clear statement:  Unfortunately I
don't have enough bandwidth to keep track of or shepherd everything
blends related, and I can't promise if/when I could look into this,
sorry.

(If you think you have read this before its a copy of Cyrils sentence
with simply s/d-i/blends/.)

Kind regards

       Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 04 Nov 2015 17:33:03 GMT) (full text, mbox, link).

Message #230 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi again,

Andreas Tille <andreas@an3as.eu> (2015-11-04):
> So the clear extract of this message is:  We need a volunteer and
> IMHO we need this *now*.
> 
> I'm convinced that Cyril will be able to give a pointer where to poke
> around […]

I'm afraid I don't have any useful knowledge in this area for the time
being. ISTR frontend limitations (list size) or usability have to be
taken into account (both in text and graphical modes), I think joeyh
mentioned those.

> (If you think you have read this before its a copy of Cyrils sentence
> with simply s/d-i/blends/.)

(That was fun. ;))

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 24 Mar 2016 09:39:03 GMT) (full text, mbox, link).

Message #235 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi folks,

I'd like to attract your attention onto bug #758116 which is requesting
a sensible selection of Blends tasks right from the installer.  While
the bug report received a lot of positive responses nobody raised up to
actually provide and test the needed code.  Since we only have nearly
six monthes to get something into such a sensible thing like the
installer I'm afraid if nobody starts now we will have another release
without such a great feature.

I wonder whether somebody who reads this list would volunteer to dive
into the details of the installer or might be able to activate a
volunteer with the necessary knowledge.

Kind regards

     Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Ole Streicher <olebole@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sun, 03 Apr 2016 10:33:03 GMT) (full text, mbox, link).

Message #240 received at 758116@bugs.debian.org (full text, mbox, reply):

Andreas Tille <andreas@an3as.eu> writes:
> I'd like to attract your attention onto bug #758116 which is requesting
> a sensible selection of Blends tasks right from the installer.

I have been looking into this a bit and think I have a (compromise)
solution.

The main problem with tasksel is that it is based on debconf that has a
very limited user interface. Basically, it can just show a list where
one can select one or more items. This makes it impossible to have a
detailed selection of all available blends with all their tasks -- the
list would just get far too long: we have currently ~270 tasks in our
blends!

So, I would propose the following: At installation time, we include for
every blend (that wants to be there) one selectable item. Selecting this
item will install

* the "tasks" package of this blend
* all available tasks (or a subset of them? to be discussed)

When starting tasksel at run time, the list will then include a list of
available tasks for the selected blend(s).

To do this technically, we could create a new package with "Priority:
important" that just contains the tasks list. This package would then
get installed with the base system and available for tasksel at
installation time (right?). This way, the blends team would keep control
over the included blends and would not need to file a bug against
tasksel every time we want to adjust this.

Does anyone veto the creation of such a package?

We would also need to create an additional  metapackage for each blend,
containing all its tasks (or a blends defined subset). Such a task would
anyway be nice to enable a "one-stop install" with apt, f.e. with "apt
install astro-all".

This proposed way to present the blends in the Debian installer is very
limited for sure - volunteers are definitely welcome here. I'd take it
as "better-than-nothing" however.

Following the bug, we should decide which blends should be presented
there. For a few, it seems obivous to me:

* Debian Astro
* Debian Med
* Debian GIS
* Hamradio
* Debian EzGo
* DebiChem (?)
* Debian Games (?)

I'd rather not include Debian Science -- I would see no user base for it
as a whole (and we can only use a single default install). What about
Debian Junior? Debian Multimedia?

And there are a few blends, that don't have tasks lists: Debian Design,
FreedomBox, DebianParl.

And, finally, there is NeuroDebian which I guess could be included, but
this would require some input from them.

Best regards

Ole

Message #245 received at 758116@bugs.debian.org (full text, mbox, reply):

Control: reassign -1 src:blends
Control: tag -1 pending

I have created the package mentioned in my last mail in the blends git
repository:

https://anonscm.debian.org/cgit/blends/blends.git/

Package: blends-tasks
Architecture: all
Priority: important
Section: misc
Depends: tasksel
Description: Debian Pure Blends tasks for new installations
 This package installs a choice of a default installation for each
 Debian Pure Blend when run from the Debian installer. The
 installation includes the tasks package of the blend, so a subsequent
 invocation of tasksel enables the choice of individual tasks.
 .
 The package is intended to be installed in the base system. Later
 (un)installation is harmless, but has no effect.

I will upload the package at the weekend if there is no further
discussion on this.

Best regards

Ole

Bug reassigned from package 'tasksel' to 'src:blends'. Request was from Ole Streicher <olebole@debian.org> to 758116-submit@bugs.debian.org. (Wed, 06 Apr 2016 15:24:11 GMT) (full text, mbox, link).

No longer marked as found in versions tasksel/3.14.1. Request was from Ole Streicher <olebole@debian.org> to 758116-submit@bugs.debian.org. (Wed, 06 Apr 2016 15:24:12 GMT) (full text, mbox, link).

Added tag(s) pending. Request was from Ole Streicher <olebole@debian.org> to 758116-submit@bugs.debian.org. (Wed, 06 Apr 2016 15:24:13 GMT) (full text, mbox, link).

Reply sent to Ole Streicher <olebole@debian.org>:
You have taken responsibility. (Mon, 11 Apr 2016 17:03:19 GMT) (full text, mbox, link).

Notification sent to Andreas Tille <tille@debian.org>:
Bug acknowledged by developer. (Mon, 11 Apr 2016 17:03:19 GMT) (full text, mbox, link).

Message #256 received at 758116-close@bugs.debian.org (full text, mbox, reply):

Source: blends
Source-Version: 0.6.93

We believe that the bug you reported is fixed in the latest version of
blends, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 758116@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ole Streicher <olebole@debian.org> (supplier of updated blends package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 09 Apr 2016 20:42:12 +0200
Source: blends
Binary: blends-dev blends-common blends-doc blends-tasks
Architecture: source all
Version: 0.6.93
Distribution: unstable
Urgency: medium
Maintainer: Debian Pure Blend Team <debian-blends@lists.debian.org>
Changed-By: Ole Streicher <olebole@debian.org>
Description:
 blends-common - Debian Pure Blends common package
 blends-dev - Debian Pure Blends common files for developing metapackages
 blends-doc - Debian Pure Blends documentation
 blends-tasks - Debian Pure Blends tasks for new installations
Closes: 758116 819425
Changes:
 blends (0.6.93) unstable; urgency=medium
 .
   [ Ole Streicher ]
   * Fix Relevance field for tasksel
   * Group tasks of one blend under a parent in tasksel
   * Update Standards-Version to 3.9.7: Change VCS-Git URL to https
   * New package blends-tasks. Closes: #758116
 .
   [ Andreas Tille ]
   * Update list of Uploaders
   * Silencing `make dist` output
   * Create xz compressed source tarballs and make tar a bit more 'predictable'
   * Re-enable dist target in rules file
     Closes: #819425
Checksums-Sha1:
 6b26bb0d6dcc848edf5b3ed82dca93fa42fe8fe9 1878 blends_0.6.93.dsc
 644f5b791efd8d9fb9c4e5a57f82128b17e20014 101832 blends_0.6.93.tar.xz
 66c29777cd46114131e5e8250a9e92a991b048b1 22852 blends-common_0.6.93_all.deb
 871037b69a9ed29a48f898e64a72a2404f5e0d5e 32432 blends-dev_0.6.93_all.deb
 9c3c4f416989efdb5a61e4f97ea2607024c1ee7c 446294 blends-doc_0.6.93_all.deb
 d39a22e577129bf547a8e826f65c1588467d0428 12550 blends-tasks_0.6.93_all.deb
Checksums-Sha256:
 18e24d485fc13fd4020cebd85f06281502d27974e534c0e665d9c39a63888ef5 1878 blends_0.6.93.dsc
 803da5b81202e1005164533874718def092a9f229fdd1e64764cdb95693536b8 101832 blends_0.6.93.tar.xz
 e338e4f60145d0cbb2dcf8dea95ae20d5f3e4388942d08250363cea40f6ceeb6 22852 blends-common_0.6.93_all.deb
 add3d296754f706c332d6cbd88f3f533532b39665576dac8b671de83c45b7be1 32432 blends-dev_0.6.93_all.deb
 33969dc3037de18da8f93ef74c59c502f79cd287fe5e3ee5efe51bd863628b0b 446294 blends-doc_0.6.93_all.deb
 1ec440e50d7e5c9d5426be965f3b8c95169aab509abe34f5905141b5b67f812e 12550 blends-tasks_0.6.93_all.deb
Files:
 e3c229bae06af9e4a055a3c3aaa0c24e 1878 devel optional blends_0.6.93.dsc
 af98624a465cebd01906599856f3f2fb 101832 devel optional blends_0.6.93.tar.xz
 a369a9291bbc8b8abbf8a40cb1339e3e 22852 misc optional blends-common_0.6.93_all.deb
 cd9add14e2c8310cf6f2122ab0ad3233 32432 devel optional blends-dev_0.6.93_all.deb
 d10d871d18f74e92ad821f4be28d20cf 446294 doc optional blends-doc_0.6.93_all.deb
 bb9ac04be9a68534832be4aaeb4df567 12550 misc important blends-tasks_0.6.93_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXCU2JAAoJEHEVr9B3ENz3ApMP/jUcqaf6B+kuUN/bYiQmRdcB
vcdRE89tvaG74XruOsEvg3xeMn9dQ3F2V2UucBex6XV8Lf2uNLHOENd2aiDi+INd
Scb+WlBR7M9BdUIa5FDsrAqTv17ggnIUUCeQi04/j0YaoE/BfezRWRP+9a05JWg3
99WhGcZWXHAhuoQTTx50zp6YvewGPLWdln7GHpQMnBnJuCJTjbrWLxcIrwYciRP1
4nLGn5RWzTEuHZ51cA7wbihhIBLGXg6h3cyX7t84L9IAJ3Hlgbrfo5u4IUr5M+fq
2mNH96uYk3/Ar3EYIMxOgYqbeYDbqdJDiBj8yLcmGlLNhZKB7+LwaFPdihZEkemR
1wi/U5IMv4nhqMfFmx2vMJrDad/5gKkg2xpeVuJvq6cVKo7W/6QlNWqeuVMeAJZY
5laiWTDDTwCaw9p502a0y3TLwldxXnq7YOGRJvFLI8cGSyHH8UKdzfocpJppvsns
aRtJk9vRCwcTfNMsms3j4RwN4VEr6f+pWyPKJNdkzvtJ4Vj7jh4HHhrWv3hUgg8J
I5oKIfnswDW6d4zqbiWxBCQImqG5it6jL/I+mxKd1qDZvF4D9geVqrkA9MvcY/6N
POXf+nxHpIrW5kX11eWG3M6O+O/1HBEg4HuEDQdNK7N07H3hYWdeCsIz3a9TyTNq
CL2Sbdd7XvaZXtGBkD+9
=oDnR
-----END PGP SIGNATURE-----

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 16 May 2016 07:27:34 GMT) (full text, mbox, link).

Bug unarchived. Request was from Cyril Brulebois <kibi@debian.org> to control@bugs.debian.org. (Tue, 17 May 2016 00:21:03 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Pure Blend Team <debian-blends@lists.debian.org>:
Bug#758116; Package src:blends. (Tue, 17 May 2016 00:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Tue, 17 May 2016 00:33:03 GMT) (full text, mbox, link).

Message #265 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

And thanks for your work on this.

Ole Streicher <olebole@debian.org> (2016-04-06):
> Control: reassign -1 src:blends
> Control: tag -1 pending
> 
> I have created the package mentioned in my last mail in the blends git
> repository:
> 
> https://anonscm.debian.org/cgit/blends/blends.git/
> 
> Package: blends-tasks
> Architecture: all
> Priority: important
> Section: misc
> Depends: tasksel
> Description: Debian Pure Blends tasks for new installations
>  This package installs a choice of a default installation for each
>  Debian Pure Blend when run from the Debian installer. The
>  installation includes the tasks package of the blend, so a subsequent
>  invocation of tasksel enables the choice of individual tasks.
>  .
>  The package is intended to be installed in the base system. Later
>  (un)installation is harmless, but has no effect.
> 
> I will upload the package at the weekend if there is no further
> discussion on this.

I'm not sure how reasonable it is to have such a long list of meta
packages in the installer. See attached tasksel-gtk-greyscale.png for
the initial display with the graphical installer, and attached
tasksel-text-greyscale.png for the text mode installer.

Also, not sure about the (lack of) ordering in Debian Pure Blends.
The Debian desktop environment submenu might be considered a bit special
(esp. after the default desktop changes…), but I don't see why the DPB
one should be unsorted. (See attached tasksel-unsorted-greyscale.png)

[ All images greyscaled to get this mail a chance to reach BTS+list. ]


KiBi.

[tasksel-gtk-greyscale.png (image/png, attachment)]

[tasksel-text-greyscale.png (image/png, attachment)]

[tasksel-unsorted-greyscale.png (image/png, attachment)]

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Ole Streicher <olebole@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Tue, 17 May 2016 06:57:03 GMT) (full text, mbox, link).

Message #270 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Cyril,

thanks for your response.

On 17.05.2016 02:13, Cyril Brulebois wrote:
> I'm not sure how reasonable it is to have such a long list of meta
> packages in the installer. See attached tasksel-gtk-greyscale.png for
> the initial display with the graphical installer, and attached
> tasksel-text-greyscale.png for the text mode installer.

I don't see it problematic as it is in the moment: The list is not too
long: Even if it does not fit on one screen, the rest is visible with
just one scroll, and this is indicated by the scroollbar. And I don't
think that the number of options is too much (it shouldn't be much more,
however).

> Also, not sure about the (lack of) ordering in Debian Pure Blends.
> The Debian desktop environment submenu might be considered a bit special
> (esp. after the default desktop changes…), but I don't see why the DPB
> one should be unsorted. (See attached tasksel-unsorted-greyscale.png)

There is no specific order of the blends. One might think of some
structuring -- many blends are somehow science related, while others are
not --, but there is not much more to say about the internal structure.
And I have no idea how to get a better order even in this sense. In the
moment, they are alphabetically sorted, and this somehow reflects the
order they appear in the blends web page [1]. It also may help to find a
specific blend. Another idea would be to sort by popconn, but this is
not transparent to the end user. And, other than that, I see nothing
that would make list f.e. Debian Astro before or after DebiChem.

To improve that, two things have to be done: First, the tasksel
mechanism should allow ordered lists (in the moment, they are
automatically sorted as long as they have the same priority) -- please
open a bug report for this, if needed. Second, we need a good idea *how*
they should be actually ordered so that a specific blend can easily be
found. Do you have a proposal?

One problem here is the limited support of debconf for structures: there
is one (hackish) level of sections (eaten up by the "Debian Pure Blends"
section), but no folding or similar. Since this is discussed now over
years without anyone actually implementing an improvement here, I doubt
that that willbe changed before the next release, so we need something
that works in the current scheme (well, unless *you* volunteer to
implement this ;-) ). And I also think that for an installer, there
should not be too much structure, since this makes the installation too
complicated. On the other hand, the current implementation is criticized
by some blends, f.e. NeuroDebian, who wishes a specific selection up to
the package level here.

Do you have any proposals what should be changed?

Best regards

Ole

[1] https://www.debian.org/blends/

Acknowledgement sent to Wolfgang Schweer <wschweer@arcor.de>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Tue, 17 May 2016 09:51:09 GMT) (full text, mbox, link).

Message #275 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, May 17, 2016 at 08:52:32AM +0200, Ole Streicher wrote:
> On 17.05.2016 02:13, Cyril Brulebois wrote:
> > I'm not sure how reasonable it is to have such a long list of meta
> > packages in the installer. See attached tasksel-gtk-greyscale.png for
> > the initial display with the graphical installer, and attached
> > tasksel-text-greyscale.png for the text mode installer.
> 
> I don't see it problematic as it is in the moment: The list is not too
> long: Even if it does not fit on one screen, the rest is visible with
> just one scroll, and this is indicated by the scroollbar. And I don't
> think that the number of options is too much (it shouldn't be much more,
> however).

I'm just wondering if the blend install could be implemented one level 
higher using the ISO image isolinux menu structure.

As an example:

It is pretty much possible to install the Debian Edu blend using the 
stock Debian mini.iso image (works, cause all udebs are fetched from the 
net in this case):

wget https://d-i.debian.org/daily-images/amd64/daily/netboot/mini.iso

On the kernel command line add: 
anna/choose_modules=debian-edu-install-udeb (the additionally needed 
debian-edu-profile-udeb will be pulled in as a dependency).

To get it working w/o touching the kernel command line, modify the ISO 
image (btxt.cfg is the blends text install config file):

modified menu.cfg
-----------------
menu hshift 7
menu width 61

menu title _Debian GNU/Linux installer boot menu
include stdmenu.cfg
include gtk.cfg
include txt.cfg
menu begin advanced
    menu label ^Advanced options
	menu title Advanced options
	include stdmenu.cfg
	label mainmenu
		menu label ^Back..
		menu exit
	include adgtk.cfg
	include adtxt.cfg
menu end
menu begin blends
    menu label ^Blend options
	menu title Blend options
	include stdmenu.cfg
	label mainmenu
		menu label ^Back..
		menu exit
	include btxt.cfg
menu end
include x86menu.cfg
label help
	menu label ^Help
	text help
   Display help screens; type 'menu' at boot prompt to return to this menu
	endtext
	config prompt.cfg
include spkgtk.cfg
include spk.cfg


added btxt.cfg (with debian-astro just as an example showing up in the menu)
----------------------------------------------------------------------------
label edu blend
	menu label Edu Blend install
	kernel linux
	append vga=788 initrd=initrd.gz anna/choose_modules=debian-edu-install-udeb --- 
label astro blend
	menu label Astro Blend install
	kernel linux
	append vga=788 initrd=initrd.gz anna/choose_modules=debian-astro-install-udeb --- 


All blends would need their own debian-<blend_name>-install-udeb and 
debian-<blend_name>-profile-udeb; these need to be on all official 
Debian installation media if these should work like the mini.iso image. 
The Debian Edu udebs could be used as examples to create blend specific 
ones:

git clone git+ssh://git.debian.org/git/debian-edu/debian-edu-install

Wolfgang

[signature.asc (application/pgp-signature, inline)]

Message #280 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Wolfgang,

On 17.05.2016 11:52, Wolfgang Schweer wrote:
> On Tue, May 17, 2016 at 08:52:32AM +0200, Ole Streicher wrote:
>> On 17.05.2016 02:13, Cyril Brulebois wrote:
>>> I'm not sure how reasonable it is to have such a long list of meta
>>> packages in the installer. See attached tasksel-gtk-greyscale.png for
>>> the initial display with the graphical installer, and attached
>>> tasksel-text-greyscale.png for the text mode installer.
>>
>> I don't see it problematic as it is in the moment: The list is not too
>> long: Even if it does not fit on one screen, the rest is visible with
>> just one scroll, and this is indicated by the scroollbar. And I don't
>> think that the number of options is too much (it shouldn't be much more,
>> however).
> 
> I'm just wondering if the blend install could be implemented one level 
> higher using the ISO image isolinux menu structure.

The advantage of the boot menu would be that in the tasksel step, one
could select individual tasks for the selected blend, and not just a
default installation. This would, however, still not allow a selection
on the package level as it was requested for NeuroDebian.

This would however add all the 13 blends to the boot menu, making this
much more crowded. And it would be impossible to select two blends at
the same time (say: science and astro).

It would also feel the Blends as being more separated from Debian
itself: you could either install "Debian", or one of the Blends. The
tasksel approach would make clear what they are in reality: a
comprehensive selection of packages and (maybe) configuration for a
specific need.

I would opt for the current solution of having it in tasksel and not in
the boot menu; especially since it is now already implemented (after two
years of discussion), with all the infrastructure and needed changes in
blends-dev in place. IMO the better solution is now to push tasksel for
a better structured package selection.

> All blends would need their own debian-<blend_name>-install-udeb and 
> debian-<blend_name>-profile-udeb; these need to be on all official 
> Debian installation media if these should work like the mini.iso image. 

Extrapolating the slow development on the common blends-install subject
in the last years (especially in bug #758116), I would not expect this
to happen before the next release. The tasksel approach also has the
advantage that it is semi-centralized: all Blends get a default install
of all their tasks, and they may adjust this in their debian-<blend>
package if needed.

Best regards

Ole

Message #285 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

(Christian: sorry for pinging you directly, but I need some longtimer
wisdom for this touchy topic.)

Hi,

Ole Streicher <olebole@debian.org> (2016-05-17):
> I don't see it problematic as it is in the moment: The list is not too
> long: Even if it does not fit on one screen, the rest is visible with
> just one scroll, and this is indicated by the scroollbar. And I don't
> think that the number of options is too much (it shouldn't be much more,
> however).

Well, I suppose this is quite a reasonable thing for someone interested
in having Debian Pure Blends in this menu to see it as non-problematic?

I'd be interested in hearing what Christian thinks about it. What is
presented to users has always been carefully weighed to make sure d-i
is flexible yet not intimidating or confusion-generating. It looks to
me we might be making a step in the wrong direction.

While this is OK(-ish) for an alpha release, this seems like something
that should be addressed before stretch is out.


> > Also, not sure about the (lack of) ordering in Debian Pure Blends.
> > The Debian desktop environment submenu might be considered a bit special
> > (esp. after the default desktop changes…), but I don't see why the DPB
> > one should be unsorted. (See attached tasksel-unsorted-greyscale.png)
> 
> There is no specific order of the blends. One might think of some
> structuring -- many blends are somehow science related, while others are
> not --, but there is not much more to say about the internal structure.
> And I have no idea how to get a better order even in this sense. In the
> moment, they are alphabetically sorted, and this somehow reflects the
> order they appear in the blends web page [1]. It also may help to find a
> specific blend. Another idea would be to sort by popconn, but this is
> not transparent to the end user. And, other than that, I see nothing
> that would make list f.e. Debian Astro before or after DebiChem.

Ah, they are kind-of alphabetically sorted, but "Hamradio" has no
"Debian", then we have some variations depending on space between Debian
and *, but not for DebianMultimedia, etc. My bad.

> To improve that, two things have to be done: First, the tasksel
> mechanism should allow ordered lists (in the moment, they are
> automatically sorted as long as they have the same priority) -- please
> open a bug report for this, if needed. Second, we need a good idea *how*
> they should be actually ordered so that a specific blend can easily be
> found. Do you have a proposal?

This was just a minor point really, we can forget about this (see
previous paragraph).

> One problem here is the limited support of debconf for structures: there
> is one (hackish) level of sections (eaten up by the "Debian Pure Blends"
> section), but no folding or similar. Since this is discussed now over
> years without anyone actually implementing an improvement here, I doubt
> that that willbe changed before the next release, so we need something
> that works in the current scheme (well, unless *you* volunteer to
> implement this ;-) ).

(If you think I'm not busy enough…)

> And I also think that for an installer, there
> should not be too much structure, since this makes the installation too
> complicated. On the other hand, the current implementation is criticized
> by some blends, f.e. NeuroDebian, who wishes a specific selection up to
> the package level here.
> 
> Do you have any proposals what should be changed?

First things first: I don't think what NeuroDebian wants is going to
happen within d-i, no. Not the place, and we have package managers for
that.

I have no idea whether the following is practical, and/or makes sense
regarding d-i's logic, etc., but I'm wondering whether it would be
possible to have checking "Debian Pure Blends" activate a follow-up
screen which would list all Blends. This way, we would get the previous
tasksel screen back, and only present the Blends to users who're
actually asking for it. And that, without changing anything in debconf,
its (non-)support for structure prompts, etc. Merging two tasks lists
obtained in two stages shouldn't be too hard, I suppose. But does that
make sense?

Again, Christian is more knowledgeable in this area, and might have more
insight.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #290 received at 758116@bugs.debian.org (full text, mbox, reply):

On 17.05.2016 13:29, Cyril Brulebois wrote:
> Ole Streicher <olebole@debian.org> (2016-05-17):
>> I don't see it problematic as it is in the moment: The list is not too
>> long: Even if it does not fit on one screen, the rest is visible with
>> just one scroll, and this is indicated by the scroollbar. And I don't
>> think that the number of options is too much (it shouldn't be much more,
>> however).
> 
> Well, I suppose this is quite a reasonable thing for someone interested
> in having Debian Pure Blends in this menu to see it as non-problematic?

Could you explain why you think it is problematic? The list is still
short (less then two screens), the Blends are well-separated (as much as
possible with debconf), for the non-iterested everything is on the first
screen, and the scrollbar clearly indicates that there is more.

> First things first: I don't think what NeuroDebian wants is going to
> happen within d-i, no. Not the place, and we have package managers for
> that.

In the moment, they place icons on the desktop to allow users to install
the major packages they want. *This* is ugly, imo. And it shows that the
current installer lacks this support, even if you (and I, BTW) don't
need it here.

> I have no idea whether the following is practical, and/or makes sense
> regarding d-i's logic, etc., but I'm wondering whether it would be
> possible to have checking "Debian Pure Blends" activate a follow-up
> screen which would list all Blends.

In the current solution, people without the need to select a blend have
everything on the first screen, and only those who want to see all
blends are required to scroll down *once*. So, it requires the same (or
even less) interaction than your proposal.

It also needs no change in the installer at all. What I would much more
like to see would be some help texts -- currently one has to guess what
"Debian EzGo" means (or "standard system utilities"). It would be nice
if tasksel would actually display the detailed description that is in
the tasks pages.

Best regards

Ole

Message #295 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, May 17, 2016 at 01:06:59PM +0200, Ole Streicher wrote:
> On 17.05.2016 11:52, Wolfgang Schweer wrote:
> > On Tue, May 17, 2016 at 08:52:32AM +0200, Ole Streicher wrote:
> >> On 17.05.2016 02:13, Cyril Brulebois wrote:
> >>> I'm not sure how reasonable it is to have such a long list of meta 
> >>> packages in the installer. See attached tasksel-gtk-greyscale.png 
> >>> for the initial display with the graphical installer, and attached 
> >>> tasksel-text-greyscale.png for the text mode installer.
> >>
> >> I don't see it problematic as it is in the moment: The list is not 
> >> too long: Even if it does not fit on one screen, the rest is 
> >> visible with just one scroll, and this is indicated by the 
> >> scroollbar. And I don't think that the number of options is too 
> >> much (it shouldn't be much more, however).
> > 
> > I'm just wondering if the blend install could be implemented one level 
> > higher using the ISO image isolinux menu structure.
> 
> The advantage of the boot menu would be that in the tasksel step, one 
> could select individual tasks for the selected blend, and not just a 
> default installation. This would, however, still not allow a selection 
> on the package level as it was requested for NeuroDebian.
> 
> This would however add all the 13 blends to the boot menu, making this
> much more crowded.

The 13 blends would only show up if 'blends options' is chosen in the 
main menu. The main menu would only have one additional entry.

> And it would be impossible to select two blends at
> the same time (say: science and astro).

Ack.

> > All blends would need their own debian-<blend_name>-install-udeb and 
> > debian-<blend_name>-profile-udeb; these need to be on all official 
> > Debian installation media if these should work like the mini.iso image. 
> 
 
> Extrapolating the slow development on the common blends-install subject
> in the last years (especially in bug #758116), I would not expect this
> to happen before the next release.

Yeah.

Wolfgang

[signature.asc (application/pgp-signature, inline)]

Message #300 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Wolfgang Schweer <wschweer@arcor.de> (2016-05-17):
> The 13 blends would only show up if 'blends options' is chosen in the 
> main menu. The main menu would only have one additional entry.

It's OK for boot options to control the type of installation/rescue you
want to be using; not really to decide which questions to ask at the
tasksel step. (Desktop choice was there for historical reasons until it
moved to tasksel.)


KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Tue, 17 May 2016 12:30:04 GMT) (full text, mbox, link).

Message #305 received at 758116@bugs.debian.org (full text, mbox, reply):

With my accessibility hat on,

Cyril Brulebois, on Tue 17 May 2016 14:23:48 +0200, wrote:
> Wolfgang Schweer <wschweer@arcor.de> (2016-05-17):
> > The 13 blends would only show up if 'blends options' is chosen in the 
> > main menu. The main menu would only have one additional entry.
> 
> It's OK for boot options to control the type of installation/rescue you
> want to be using; not really to decide which questions to ask at the
> tasksel step. (Desktop choice was there for historical reasons until it
> moved to tasksel.)

Also, the boot menu is not accessible, and I doubt it will be in any
close or mid-term future.

Samuel

Acknowledgement sent to Steve McIntyre <steve@einval.com>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Tue, 17 May 2016 13:42:04 GMT) (full text, mbox, link).

Message #310 received at 758116@bugs.debian.org (full text, mbox, reply):

On Tue, May 17, 2016 at 02:23:48PM +0200, Cyril Brulebois wrote:
>Wolfgang Schweer <wschweer@arcor.de> (2016-05-17):
>> The 13 blends would only show up if 'blends options' is chosen in the 
>> main menu. The main menu would only have one additional entry.
>
>It's OK for boot options to control the type of installation/rescue you
>want to be using; not really to decide which questions to ask at the
>tasksel step. (Desktop choice was there for historical reasons until it
>moved to tasksel.)

Exactly - it's much better to have it later. Imagine if the top-level
boot menu permutations along with speech installation, advanced, etc...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Pure Blend Team <debian-blends@lists.debian.org>:
Bug#758116; Package src:blends. (Wed, 18 May 2016 05:24:04 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Wed, 18 May 2016 05:24:04 GMT) (full text, mbox, link).

Message #315 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi,

[due to traveling to some Debian Med related workshop in Paris I was a bit
 offline-ish - so I become involved a bit late into this discussion and
 just add my points where I think further input might be helpful.]

On Tue, May 17, 2016 at 02:00:14PM +0200, Ole Streicher wrote:
> 
> > I have no idea whether the following is practical, and/or makes sense
> > regarding d-i's logic, etc., but I'm wondering whether it would be
> > possible to have checking "Debian Pure Blends" activate a follow-up
> > screen which would list all Blends.
> 
> In the current solution, people without the need to select a blend have
> everything on the first screen, and only those who want to see all
> blends are required to scroll down *once*. So, it requires the same (or
> even less) interaction than your proposal.

Structure wise I agree with Cyril that some follow-up screen would make
some sense provided that we have some explanation what "Debian Pure
Blends" are.

> It also needs no change in the installer at all. What I would much more
> like to see would be some help texts -- currently one has to guess what
> "Debian EzGo" means (or "standard system utilities"). It would be nice
> if tasksel would actually display the detailed description that is in
> the tasks pages.

Fully agreed here that some extra information would be really helpful
(fully orthogonal to the Blends topic).  I personally decided to go with
the minimum selected tasks since I was lacking information what the
tasks might be install on my box.

As a conclusion I agree with Ole that his current proposed solution is
acceptable for practical cases since it does not require any additional
user interaction and we do not have the technique that might be needed
to realise other more structured solutions.

Kind regards

    Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Wed, 18 May 2016 05:36:03 GMT) (full text, mbox, link).

Message #320 received at 758116@bugs.debian.org (full text, mbox, reply):

(thanks for prodding me...you never know, indeed, though I still read 
-boot...;-) )

> I have no idea whether the following is practical, and/or makes sense
> regarding d-i's logic, etc., but I'm wondering whether it would be
> possible to have checking "Debian Pure Blends" activate a follow-up
> screen which would list all Blends. This way, we would get the previous
> tasksel screen back, and only present the Blends to users who're
> actually asking for it. And that, without changing anything in debconf,
> its (non-)support for structure prompts, etc. Merging two tasks lists
> obtained in two stages shouldn't be too hard, I suppose. But does that
> make sense?
>
> Again, Christian is more knowledgeable in this area, and might have more
> insight.

I tried to read the whole thread and then I'll summarize my thoughts.

At first, I'm not happy with the idea of Pure Blends tasks mixing up 
with standard tasks. I fully respect the work done by the variou sblends 
teams, but having our usual longstanding "standard" tasks kinda lost in 
the middle of "strange" and obscure tasks which the average user has no 
idea about what they're about...is a no-no for me.

I still remember Joey's objections about *not* having users forced to 
choose between desktop environments....because, contrary to what the 
average geek thinks, most people have no idea about what is a desktop 
environment. So, just imagine if we present them with "Hamradio", 
"NeuroDebian", "Debian Med" and such a list of unsorted strange things.

Not to mention that most of these tasks titles wouldn't be translated, 
while other tasks are.

So, yes, I'd object strongly to mixing up Blends tasks with other tasks.

I think that the idea of blends choice in the boot menu has already 
ruled out for several reasons, so I won't develop here, but just add one 
more reason : this is untranslatable.

That leaves us with the idea of a "Debian Blends" choice in the standard 
task menu, which would lead to a dedicated "blends" menu. I think this 
is the best compromise to do, provided we find a good name for the menu 
entry : "Debian Blends" or "Debian pure Blends" is a great name for the 
project in its entirety...but probably not for the menu entry. Again, 
because it means nothing to Joe User.

So, with something like "Special-purpose packages" or "Specialized 
installations" or whatever along those lines, *then* a menu with the 
Blends list (unsorted) and the possibility of going back just in case 
people see the list and think "heck, I have no idea about what this 
stuff is about"....then I'd say this is the way to go.

Acknowledgement sent to Ole Streicher <olebole@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Wed, 18 May 2016 07:45:03 GMT) (full text, mbox, link).

Message #325 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Christian,

I agree that the best compromise would probably be to have a separate
page "Debian Pure Blends". But someone should implement this -- any
volunteers? I myself don't have enough Perl knowledge to do this.

However, I don't understand your rationale here:

Am 18.05.2016 um 07:25 schrieb Christian Perrier:
> At first, I'm not happy with the idea of Pure Blends tasks mixing up
> with standard tasks. I fully respect the work done by the variou
> sblends teams, but having our usual longstanding "standard" tasks
> kinda lost in the middle of "strange" and obscure tasks which the
> average user has no idea about what they're about...is a no-no for
> me.

The "standard" task is IMO one of the concepts in this step that
actually *nobody* understands: I myself don't know what it means, and
all the people I asked (when I presented the current scheme of
installing the blends) have no idea what happens if they (de)select this.

The help text in the tasks file (which is anyway not displayed in
tasksel) does not help: f.e. if I want to use Debian for web browsing
and e-mail, shall I install it? If I am a Java developer? The "standard"
task itself is "obscure"; IMO even more than an "DebiChem" task (where
already the name suggests that you don't need it if you are not
interested in chemistry).

> I still remember Joey's objections about *not* having users forced
> to choose between desktop environments....because, contrary to what
> the average geek thinks, most people have no idea about what is a
> desktop environment. So, just imagine if we present them with
> "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> strange things.

So, if the average user doesn't have a glue about a Desktop environment,
why is it offered in the installation by default? You seem to contradict
to your own arguments here.

In my opinion, the situation for the Debian Pure Blends is better here
than for the Desktop environments: If a user doesn't know what the
Blends mean, he just ignores it and doesn't install anything from it.
This will cause no harm -- he will just not get something he anyway
doesn't know about. But if a user doesn't understand what a "Desktop
environment" is and therefore decides to not install it, he may left
with an installation that he did not expect, and may have no chance to
correct this without external help. Therefore it may be better to hide
the desktop environment choice as well.

> That leaves us with the idea of a "Debian Blends" choice in the
> standard task menu, which would lead to a dedicated "blends" menu. I
> think this is the best compromise to do, provided we find a good name
> for the menu entry : "Debian Blends" or "Debian pure Blends" is a
> great name for the project in its entirety...but probably not for the
> menu entry. Again, because it means nothing to Joe User.
> 
> So, with something like "Special-purpose packages" or "Specialized 
> installations" or whatever along those lines, *then* a menu with the 
> Blends list (unsorted) and the possibility of going back just in
> case people see the list and think "heck, I have no idea about what
> this stuff is about"....then I'd say this is the way to go.
> 

I personally don't have problems with changing this; however this would
open again the discussion about the names -- IMO we should be consistent
here. We can't call them "Specialized Installations" in the installer,
but "Debian Pure Blends" on the web page. Renaming would have a tail of
renaming it everywhere.

So, I would propose to explain the name and the concept in the
installer. There is already some text in the debian-blends-tasks.desc
that would help to explain it -- it should just be displayed. Again, it
would help much if tasksel would be able to display the help texts that
are already there, and IMO if the programming efforts are limited, we
would gain more in implementing help texts instead of separating the
blends from the desktop environments.

Best regards

Ole

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Wed, 18 May 2016 09:00:07 GMT) (full text, mbox, link).

Message #330 received at 758116@bugs.debian.org (full text, mbox, reply):

[Ole Streicher]
> In my opinion, the situation for the Debian Pure Blends is better here
> than for the Desktop environments: If a user doesn't know what the
> Blends mean, he just ignores it and doesn't install anything from it.

An unskilled user do not ignore options he do not understand, he worries
and tries to understand them in order to avoid making a mistake that
will bother him in the future.  If you believe options that are unknown
or confusing do not cause any harm, I am quite sure you are mistaken.
They increase the cognitive strain and force people to spend time trying
to understand that the option can be ignored.  They also slow down the
installation process.

Note, I am not against the blends selection option during installation,
but believe it should be introduced after taking the negative effects as
well as the positive effects into account, not by claiming the negative
effects do not exist.

There exist usability research indicating that more than 7 options will
confuse the human brain and cause a lot of cognitive strain.  To me it
tell us that we should avoid "just two screenfulls" of options, and
instead try to make sure at most one screenfull, and preferably less
than 7 options are presented in any dialog in the installer.

-- 
Happy hacking
Petter Reinholdtsen

Acknowledgement sent to Ole Streicher <olebole@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Wed, 18 May 2016 10:36:03 GMT) (full text, mbox, link).

Message #335 received at 758116@bugs.debian.org (full text, mbox, reply):

On 18.05.2016 10:58, Petter Reinholdtsen wrote:
> [Ole Streicher]
>> In my opinion, the situation for the Debian Pure Blends is better here
>> than for the Desktop environments: If a user doesn't know what the
>> Blends mean, he just ignores it and doesn't install anything from it.
> 
> An unskilled user do not ignore options he do not understand, he worries
> and tries to understand them in order to avoid making a mistake that
> will bother him in the future.  If you believe options that are unknown
> or confusing do not cause any harm, I am quite sure you are mistaken.
> They increase the cognitive strain and force people to spend time trying
> to understand that the option can be ignored.  They also slow down the
> installation process.

Again, this questiones the whole tasksel step during the installation:
As Christian points out, the majority of users doesn't understand what
"Desktop Environment" means, especially if is should decide whether he
needs "Cinnamon" or "Mate".

My own experiences are that I don't know anyone who understands the
"standard tools" item.

Compared to that, "DebiChem" is understandable: That has something to do
with chemistry. If the help would have been displayed, then he could
also know it. He then could also understand what a "Pure Blend" is. It
may help him to understand what a "Desktop environment" is. And maybe
someone finds a smart help text for the "standard tools".

If we really care that people should understand what they see, the first
issue *should* be to implement the help texts here.

> Note, I am not against the blends selection option during installation,
> but believe it should be introduced after taking the negative effects as
> well as the positive effects into account, not by claiming the negative
> effects do not exist.

I claim that they do not increase much. The issues are already there.

> There exist usability research indicating that more than 7 options will
> confuse the human brain and cause a lot of cognitive strain.  To me it
> tell us that we should avoid "just two screenfulls" of options, and
> instead try to make sure at most one screenfull, and preferably less
> than 7 options are presented in any dialog in the installer.

This is already violated in some steps of the installation. And we
already have 13 Blends; I don't see a good way to squeeze them into 7.

Best regards

Ole

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Pure Blend Team <debian-blends@lists.debian.org>:
Bug#758116; Package src:blends. (Thu, 19 May 2016 05:51:04 GMT) (full text, mbox, link).

Acknowledgement sent to Christian PERRIER <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Thu, 19 May 2016 05:51:04 GMT) (full text, mbox, link).

Message #340 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Quoting Ole Streicher (olebole@debian.org):

> The "standard" task is IMO one of the concepts in this step that
> actually *nobody* understands: I myself don't know what it means, and
> all the people I asked (when I presented the current scheme of
> installing the blends) have no idea what happens if they (de)select this.

Longstanding "issue". It installs packages of priority "standard", so
that brings us to the definition of these "standard" packages. IIRC
(but I even don't remember where it lies) I spent hours thinking about
the "right" way to translate the "standard" task name into French.

Anyway, the "standard" tasks I was talking about are the other tasks
in tasksel, not "standard" itself.


> > I still remember Joey's objections about *not* having users forced
> > to choose between desktop environments....because, contrary to what
> > the average geek thinks, most people have no idea about what is a
> > desktop environment. So, just imagine if we present them with
> > "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> > strange things.
> 
> So, if the average user doesn't have a glue about a Desktop environment,
> why is it offered in the installation by default? You seem to contradict
> to your own arguments here.

Because there has always been a contradiction..:-)

In the past, precisely for these reasons, the D.E. tasks were not
presented to users. However, over time, we had more and more and more
requests to allow this and it finally got enabled, but nnot really
with great enthusiasm...:-). This is kinda acknowledging that, indeed,
Debian installations from scratch with user's manual interaction is
now more something that skilled users are doing (let's face reality :
is Debian really used and installed by unskilled users
nowadays...certainly not).

So, more or less, we currently already are in a kind of compromise
which will never satisfy everybody....

About the name of the "Debian Blends" menu entry : I have no intent to
rename the project, but more to present users with a meaningful
choice. Holger's suggestion in this thread seems to be the way to go
--> keep "Debian Blends" but explain in a few words what it is.

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Pure Blend Team <debian-blends@lists.debian.org>:
Bug#758116; Package src:blends. (Fri, 20 May 2016 07:45:03 GMT) (full text, mbox, link).

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Fri, 20 May 2016 07:45:03 GMT) (full text, mbox, link).

Message #345 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Christian,

Christian Perrier <bubulle@debian.org> (2016-05-18):
> (thanks for prodding me...you never know, indeed, though I still read
> -boot...;-) )

(wow, great!)

> >I have no idea whether the following is practical, and/or makes sense
> >regarding d-i's logic, etc., but I'm wondering whether it would be
> >possible to have checking "Debian Pure Blends" activate a follow-up
> >screen which would list all Blends. This way, we would get the previous
> >tasksel screen back, and only present the Blends to users who're
> >actually asking for it. And that, without changing anything in debconf,
> >its (non-)support for structure prompts, etc. Merging two tasks lists
> >obtained in two stages shouldn't be too hard, I suppose. But does that
> >make sense?
> >
> >Again, Christian is more knowledgeable in this area, and might have more
> >insight.
> 
> I tried to read the whole thread and then I'll summarize my thoughts.
> 
> At first, I'm not happy with the idea of Pure Blends tasks mixing up with
> standard tasks. I fully respect the work done by the variou sblends teams,
> but having our usual longstanding "standard" tasks kinda lost in the middle
> of "strange" and obscure tasks which the average user has no idea about what
> they're about...is a no-no for me.

Ack. Not a surprise to me, but thanks for confirming. :)

> I still remember Joey's objections about *not* having users forced to choose
> between desktop environments....because, contrary to what the average geek
> thinks, most people have no idea about what is a desktop environment. So,
> just imagine if we present them with "Hamradio", "NeuroDebian", "Debian Med"
> and such a list of unsorted strange things.
> 
> Not to mention that most of these tasks titles wouldn't be translated, while
> other tasks are.
> 
> So, yes, I'd object strongly to mixing up Blends tasks with other tasks.

Ack.

> I think that the idea of blends choice in the boot menu has already ruled
> out for several reasons, so I won't develop here, but just add one more
> reason : this is untranslatable.

Ack.

> That leaves us with the idea of a "Debian Blends" choice in the standard
> task menu, which would lead to a dedicated "blends" menu. I think this is
> the best compromise to do, provided we find a good name for the menu entry :
> "Debian Blends" or "Debian pure Blends" is a great name for the project in
> its entirety...but probably not for the menu entry. Again, because it means
> nothing to Joe User.
> 
> So, with something like "Special-purpose packages" or "Specialized
> installations" or whatever along those lines, *then* a menu with the Blends
> list (unsorted) and the possibility of going back just in case people see
> the list and think "heck, I have no idea about what this stuff is
> about"....then I'd say this is the way to go.

While deciding the exact label (and getting it translated) might be
tricky indeed, let's see if we can come up with a working implementation
past D-I Stretch Alpha 6, then.

The person looking into this (hello future self?) should remember
preseeding should be supported, as well as going back.

Thanks so much, Christian.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Fri, 20 May 2016 08:33:08 GMT) (full text, mbox, link).

Message #350 received at 758116@bugs.debian.org (full text, mbox, reply):

On Fri, May 20, 2016 at 09:42:47AM +0200, Cyril Brulebois wrote:
> Christian Perrier <bubulle@debian.org> (2016-05-18):
> > (thanks for prodding me...you never know, indeed, though I still read
> > -boot...;-) )
> 
> (wow, great!)

May be some OT chatting about super marathons might keep Bubulle
attracted. :-P
 
> > So, with something like "Special-purpose packages" or "Specialized
> > installations" or whatever along those lines, *then* a menu with the Blends
> > list (unsorted) and the possibility of going back just in case people see
> > the list and think "heck, I have no idea about what this stuff is
> > about"....then I'd say this is the way to go.
> 
> While deciding the exact label (and getting it translated) might be
> tricky indeed, let's see if we can come up with a working implementation
> past D-I Stretch Alpha 6, then.

Sounds good.
 
> The person looking into this (hello future self?) should remember
> preseeding should be supported, as well as going back.

If there are any tasks that do not require any detailed knowledge of the
installer please feel free to throw them here on the Blends list.  We
really appreciate your effort into the installer and try to get at least
parts of work from your shoulders.

Kind regards

      Andreas.

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Pure Blend Team <debian-blends@lists.debian.org>:
Bug#758116; Package src:blends. (Sat, 21 May 2016 20:51:03 GMT) (full text, mbox, link).

Acknowledgement sent to Martin Michlmayr <tbm@cyrius.com>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sat, 21 May 2016 20:51:04 GMT) (full text, mbox, link).

Message #355 received at 758116@bugs.debian.org (full text, mbox, reply):

* Christian Perrier <bubulle@debian.org> [2016-05-18 07:25]:
> I still remember Joey's objections about *not* having users forced
> to choose between desktop environments....because, contrary to what
> the average geek thinks, most people have no idea about what is a
> desktop environment.  So, just imagine if we present them with
> "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> strange things.

FWIW, I fully agree.  I'm not happy to see the new desktop selection
in tasksel, even though I can understand why some people want to see
this.  In my opinion, adding Blends is definitely taking things too
far.  Most users will have no clue what it's about, even if we add an
explanation of what a "blend" is.

We've worked hard for years to improve the installation experience and I
fear the new tasksel selection will add a lot of confusion for users.

-- 
Martin Michlmayr
http://www.cyrius.com/

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sat, 21 May 2016 21:00:04 GMT) (full text, mbox, link).

Message #360 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

Martin Michlmayr <tbm@cyrius.com> (2016-05-21):
> * Christian Perrier <bubulle@debian.org> [2016-05-18 07:25]:
> > I still remember Joey's objections about *not* having users forced
> > to choose between desktop environments....because, contrary to what
> > the average geek thinks, most people have no idea about what is a
> > desktop environment.  So, just imagine if we present them with
> > "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> > strange things.
> 
> FWIW, I fully agree.  I'm not happy to see the new desktop selection
> in tasksel, even though I can understand why some people want to see
> this.  In my opinion, adding Blends is definitely taking things too
> far.  Most users will have no clue what it's about, even if we add an
> explanation of what a "blend" is.

OK; so that's not just me.

> We've worked hard for years to improve the installation experience and I
> fear the new tasksel selection will add a lot of confusion for users.

For now, I've added a mention about the new (possibly temporary)
behaviour regarding tasksel:
  https://www.debian.org/devel/debian-installer/News/2016/20160521


Now that I'm almost done with releasing D-I Stretch Alph 6, I've looked
at how we got there. It seems blends-tasks is Priority: important, and
that's how it got into the installed system.

Then looking at tasksel's README:
| On startup, the tasksel program will read all *.desc files in
| /usr/share/tasksel/ for information about what tasks are available. The
| tasks will be presented in a simple list selection screen with their
| short descriptions.

I'm very much not happy with tasksel's picking up whatever people have
managed to get into a basic system, and I would very much prefer if it
would only look at its own debian-tasks.desc when running from the
installer. Any objections?


Also, Steve mentioned the Debian Pure Blends addition might generate
issues depending on what blends are available and/or installable on this
or that image (adding debian-cd@ for reference).


KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sat, 21 May 2016 21:15:04 GMT) (full text, mbox, link).

Message #365 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Cyril Brulebois <kibi@debian.org> (2016-05-21):
> I'm very much not happy with tasksel's picking up whatever people have
> managed to get into a basic system, and I would very much prefer if it
> would only look at its own debian-tasks.desc when running from the
> installer. Any objections?

As a side note, pkgsel calls tasksel with --new-install, but maybe
others are using this flag outside d-i contexts. So I'd probably add
a --internal-tasks-only there.

As another side note, tasksel-data in Debian only has:
  /usr/share/tasksel/descs/debian-tasks.desc

while latest Ubuntu has:
  /usr/share/tasksel/descs/debian-tasks.desc
  /usr/share/tasksel/descs/ubuntu-tasks.desc

so it would be nice to support all desc files shipped in tasksel-data
rather than hardcoding debian-tasks.desc when the --internal-tasks-only
flag is passed.

Martin, I think this would go along the lines of the idea you mentioned
briefly on IRC?


KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sat, 21 May 2016 21:27:03 GMT) (full text, mbox, link).

Message #370 received at 758116@bugs.debian.org (full text, mbox, reply):

[Cyril Brulebois]
> I'm very much not happy with tasksel's picking up whatever people have
> managed to get into a basic system, and I would very much prefer if it
> would only look at its own debian-tasks.desc when running from the
> installer. Any objections?

Yes.

Debian Edu uses the current behaviour to install its tasks during
installation, but we do not use standard priority tasks to get into the
installer, we use udebs to trigger the installation of education-tasks.

Being able to add extra tasks using udebs is a feature, not a bug.

-- 
Happy hacking
Petter Reinholdtsen

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sat, 21 May 2016 21:45:04 GMT) (full text, mbox, link).

Message #375 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Petter Reinholdtsen <pere@hungry.com> (2016-05-21):
> [Cyril Brulebois]
> > I'm very much not happy with tasksel's picking up whatever people have
> > managed to get into a basic system, and I would very much prefer if it
> > would only look at its own debian-tasks.desc when running from the
> > installer. Any objections?
> 
> Yes.
> 
> Debian Edu uses the current behaviour to install its tasks during
> installation, but we do not use standard priority tasks to get into the
> installer, we use udebs to trigger the installation of education-tasks.
> 
> Being able to add extra tasks using udebs is a feature, not a bug.

There's no udebs involved in what I summarized for Blends.


Also: If pkgsel changes the way it calls tasksel, debian-edu udebs can
certainly interact with it so that it behaves as desired.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sat, 21 May 2016 22:12:03 GMT) (full text, mbox, link).

Message #380 received at 758116@bugs.debian.org (full text, mbox, reply):

[Cyril Brulebois]
> There's no udebs involved in what I summarized for Blends.

Exactly.  I suspect using udebs to enable blends is be a better idea
than making the Blends tasksel tasks priority standard.

> Also: If pkgsel changes the way it calls tasksel, debian-edu udebs can
> certainly interact with it so that it behaves as desired.

You misunderstand the role of the udebs.  The Debian Edu udeb ask for
education-tasks to be installed, and then the normal d-i take care of
the rest to get the correct Debian Edu tasks installed using tests and
the locale settings.  Sure, we can come up with a new way to do it, but
my point is that we are using this feature of tasksel today, and there
is no alternative I know of that is equally robust and well integrated
into the installer.

-- 
Happy hacking
Petter Reinholdtsen

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Pure Blend Team <debian-blends@lists.debian.org>:
Bug#758116; Package src:blends. (Sun, 22 May 2016 10:15:04 GMT) (full text, mbox, link).

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sun, 22 May 2016 10:15:04 GMT) (full text, mbox, link).

Message #385 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Petter Reinholdtsen <pere@hungry.com> (2016-05-22):
> [Cyril Brulebois]
> > There's no udebs involved in what I summarized for Blends.
> 
> Exactly.

Thanks for confirming that your “Being able to add extra tasks using
udebs is a feature, not a bug.” wasn't really on topic then.

> I suspect using udebs to enable blends is be a better idea than
> making the Blends tasksel tasks priority standard.

Having this kind of move forced on us doesn't seem reasonable to me,
which has been exactly my point over the past few mails.

Let me reiterate: I don't want this to happen ever again.


> > Also: If pkgsel changes the way it calls tasksel, debian-edu udebs can
> > certainly interact with it so that it behaves as desired.
> 
> You misunderstand the role of the udebs.

Please explain how you came to that conclusion.

> The Debian Edu udeb ask for education-tasks to be installed, and
> then the normal d-i take care of the rest to get the correct Debian
> Edu tasks installed using tests and the locale settings.  Sure, we
> can come up with a new way to do it, but my point is that we are
> using this feature of tasksel today, and there is no alternative I
> know of that is equally robust and well integrated into the
> installer.

What? I'm talking about a future evolution. I can't see why something
using a pre-pkgsel.d hook to prepare things for d-i couldn't be
updated to create e.g. an extra file to get pkgsel to behave as
intended. I don't see why such implementation details would be
important in this discussion, and that's why I mentioned “debian-edu
udebs can certainly interact with it so that it behaves as desired”.

Pretty sure I'm not the one “misunderstanding” anything here.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sun, 22 May 2016 10:21:03 GMT) (full text, mbox, link).

Message #390 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

two more ideas from irc:

< pabs> KiBi, tbm: re blends/desktops stuff, what about showing that only in
         expert mode?
< h01ger> or a dedicated image, which uses a kernel cmdline param to enable 
         blends-mode…


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sun, 22 May 2016 10:39:08 GMT) (full text, mbox, link).

Message #395 received at 758116@bugs.debian.org (full text, mbox, reply):

[Cyril Brulebois]
> Please explain how you came to that conclusion.

I'm sorry, but the thread so far do not make me believe you are not
really want to understand what I mean, but instead look for a way to
push your view and any explanation I come up with would be brushed away.

I believe it is best for me to not get involved in d-i.  To me, based on
the current and earlier email and IRC exchanges, d-i development seem
like a toxic environment and I believe my effort is better spent
elsewhere.  Thus I do not see the point of spending the time to try to
explain why and how my view is fundamentally different from yours, as I
am conviced the effort will be wasted.  It make me sad, but I just do
not have the energy to try to do something about it.

I was hoping to work on hw-detect and isenkram integration, but have not
been able to muster the motivation to do it so far.  I will probably
limit myself to adding an udeb for isenkram and leave the d-i part to
others, even if it probably mean automatic firmware setup will not
become part of the official installer.

I suspect the cause is just a question of incompatible personalities
involved, and either that the culture was different back when we ran the
d-i project at the start or that I changed so much the culture is no
longer friendly to me.

-- 
Happy hacking
Petter Reinholdtsen

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sun, 22 May 2016 14:48:08 GMT) (full text, mbox, link).

Message #400 received at 758116@bugs.debian.org (full text, mbox, reply):

On Sun, May 22, 2016 at 10:18:42AM +0000, Holger Levsen wrote:
> Hi,
> 
> two more ideas from irc:
> 
> < pabs> KiBi, tbm: re blends/desktops stuff, what about showing that only in
>          expert mode?

I'm not sure whether "expert mode" fits the intended user target group.

> < h01ger> or a dedicated image, which uses a kernel cmdline param to enable 
>          blends-mode…

I think this is a good hint.  I admit the thread went in three ways out
of my competence:  One are technical details I have not dealt with
before, one is the installer philosophy I have not thought deeply about
and finally there seem to be personal issues involved I can't sensibly
comment on.

So I'd like to summarise the intention of bug #758116:  We need to find
a sensible answer to the question that is asked by users whenever I'm
talking about Blends:  How can I easily install a Blend?

Kind regards

        Andreas.

-- 
http://fam-tille.de

Acknowledgement sent to Ole Streicher <olebole@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Sun, 22 May 2016 18:45:10 GMT) (full text, mbox, link).

Message #405 received at 758116@bugs.debian.org (full text, mbox, reply):

Hi Cyril,

Am 21.05.2016 um 23:11 schrieb Cyril Brulebois:
> so it would be nice to support all desc files shipped in tasksel-data
> rather than hardcoding debian-tasks.desc when the --internal-tasks-only
> flag is passed.

If you want to do it in the way it was proposed some days ago (move the
blends and the desktop choice into separate pages):

You could use a "Section" keyword in the tasks header: this is already
there for the structuration of tasks. Then the "main" task would just
display everything without a section, and one option for each section
(currently "Desktop Environment" and "Debian Pure Blends"). Enabling
these options leads to follow-up screens showing their content.

Aside from keeping the initial tasksel screen clean, this would also
naturally remove the confusing checkboxes that are currently on the
sections headers.

Best regards

Ole

Acknowledgement sent to Sunil Mohan Adapa <sunil@medhas.org>:
Extra info received and forwarded to list. Copy sent to Debian Pure Blend Team <debian-blends@lists.debian.org>. (Wed, 25 May 2016 06:15:04 GMT) (full text, mbox, link).

Message #410 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hello,

Here is an experimental patch to perform package installation using
PackageKit.  I have tested it for success and error conditions but there
are corner cases such as inserting devices during package installation
and parallel package installation that I haven't tested.  I expect them
to work fine by the way.

One thing to consider about PackageKit is that it does not show progress
dialogs like aptdaemon.  But I have left some code in there to collect
progress information that can be used to show progress dialogs if necessary.

-- 
Sunil

[0001-Implement-package-installation-using-PackageKit.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #415 received at 758116@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 05/25/2016 11:42 AM, Sunil Mohan Adapa wrote:
> Hello,
> 
> Here is an experimental patch to perform package installation using
> PackageKit.  I have tested it for success and error conditions but there
> are corner cases such as inserting devices during package installation
> and parallel package installation that I haven't tested.  I expect them
> to work fine by the way.

Sorry, I sent the patch to the wrong bug.  Please ignore.

-- 
Sunil

[signature.asc (application/pgp-signature, attachment)]

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 22 Jun 2016 07:26:58 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Tue Jan 30 06:51:20 2024; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #758116 tasksel: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

Debian Bug report logs - #758116
tasksel: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough