Discussion:
Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
(too old to reply)
Andreas Tille
2014-10-08 09:45:24 UTC
Permalink
Hi Cyril,
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
Cyril Brulebois
2014-10-14 04:02:11 UTC
Permalink
Hi Andreas,
Post by Andreas Tille
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.
Andreas Tille
2014-10-14 08:01:22 UTC
Permalink
Hi Cyril,
Post by Cyril Brulebois
Hi Andreas,
Post by Andreas Tille
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].
Post by Cyril Brulebois
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]).
Post by Cyril Brulebois
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.
Post by Cyril Brulebois
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.
Post by Cyril Brulebois
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.
Post by Cyril Brulebois
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] Loading Image...
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#135
--
http://fam-tille.de
Cyril Brulebois
2014-10-14 08:14:53 UTC
Permalink
Hi again Andreas,
Post by Andreas Tille
Post by Cyril Brulebois
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.
Post by Andreas Tille
Post by Cyril Brulebois
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.
Post by Andreas Tille
Post by Cyril Brulebois
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. ;)
Post by Andreas Tille
Post by Cyril Brulebois
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.
Post by Andreas Tille
Post by Cyril Brulebois
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.
Andreas Tille
2014-10-14 09:20:02 UTC
Permalink
Hi Cyril,
Post by Cyril Brulebois
Post by Andreas Tille
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.
Post by Cyril Brulebois
Post by Andreas Tille
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.
Post by Cyril Brulebois
Post by Andreas Tille
...
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).
Post by Cyril Brulebois
Post by Andreas Tille
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.
Post by Cyril Brulebois
Post by Andreas Tille
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.
Post by Cyril Brulebois
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.
Post by Cyril Brulebois
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@an3as.eu
Bas Wijnen
2014-10-14 17:19:36 UTC
Permalink
Post by Andreas Tille
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. 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.

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

Is this a good 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".

Regardless of whether my summary is good, I think the documentation can
use some improvement. Examples of the target audience would be useful.
What is made possible or easier with blends? What is often confused
with it, but isn't actually related? 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.
Post by Andreas Tille
Post by Andreas Tille
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.

Thanks,
Bas
Jonas Smedegaard
2014-10-14 18:29:47 UTC
Permalink
Quoting Bas Wijnen (2014-10-14 19:19:36)
I have heard about [Blends] 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. 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.
[snip]

This is the canonical definition:
https://wiki.debian.org/DebianPureBlends#Terminology

If that's the text you found confusing, please do help by elaborating
what was confusing about it.
Post by Andreas Tille
Well, Blends and "the desktop situation" could be considered orthogonal.
Do all blends work well with all desktop environments?
No.
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.
Good point!


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

[x] quote me freely [ ] ask before reusing [ ] keep private
Andreas Tille
2014-10-14 21:57:50 UTC
Permalink
Hi,
Post by Bas Wijnen
Post by Andreas Tille
Well, Blends and "the desktop situation" could be considered orthogonal.
Do all blends work well with all desktop environments?
No.
While this "no" means: There exist 1 or 2 Blends focussing on a
specific desktop environment (as far as I know Debian Edu and Ezgo) but
others work perfectly well under all desktop environments. So the
answer is mathematical correct but a bit short to understand the full
picture.

Kind regards

Andreas.

PS: I'll answer Bas' question tomorrow in more detail but I'm to
tired today.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-blends-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@an3as.eu
Andreas Tille
2014-10-15 09:16:29 UTC
Permalink
Hi Holger,
Hi,
Post by Andreas Tille
While this "no" means: There exist 1 or 2 Blends focussing on a
specific desktop environment (as far as I know Debian Edu and Ezgo) but
Debian Edu offers you the documented choices between KDE Plasma (default),
Gnome, Mate, Xfce4, LXDE and Sugar. (And for jessie+1 hopefully Cinnamon too.)
And as the documentation also says you can apt-get install anything else you
wish from Debian too.
So no, Debian Edu doesnt focus on a specific desktop anymore. A few years ago
KDE was *the* choice, but iirc that was until ~2009 or 10.
Thanks for the clarification. In this case I'd answer the question from
Bas
Do all blends work well with all desktop environments?
rather with "yes".

I'll send this to the other lists where the question came up to. At
some point we should stop cross-posting to several lists, but since the
topic about the installer is relevant for debian-boot as well I'm not
sure whether it is good to leave this out.

Kind regards

Andreas.
--
http://fam-tille.de
Andreas Tille
2014-10-15 07:31:36 UTC
Permalink
Hi Bas,
Post by Bas Wijnen
Post by Andreas Tille
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].
Post by Bas Wijnen
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.
Post by Bas Wijnen
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.
Post by Bas Wijnen
Is this a good summary?
I hope I added some more points to this summary.
Post by Bas Wijnen
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. :-)
Post by Bas Wijnen
Regardless of whether my summary is good, I think the documentation can
use some improvement.
+1
That's always needed.
Post by Bas Wijnen
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.
Post by Bas Wijnen
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).
Post by Bas Wijnen
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 :-()
Post by Bas Wijnen
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?
Post by Bas Wijnen
Post by Andreas Tille
Post by Andreas Tille
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
Bas Wijnen
2014-10-15 17:49:32 UTC
Permalink
Hi,
Post by Andreas Tille
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!
Post by Andreas Tille
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.
Post by Andreas Tille
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.
Post by Andreas Tille
- 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.)
Post by Andreas Tille
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?
Post by Andreas Tille
I hope I added some more points to this summary.
Yes, thank you.
Post by Andreas Tille
Post by Bas Wijnen
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?
Post by Andreas Tille
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.
Post by Andreas Tille
Post by Bas Wijnen
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.
Post by Andreas Tille
Hope this additional explanation helps
Yes, thanks!
Bas
Jonas Smedegaard
2014-10-15 19:37:10 UTC
Permalink
Quoting Bas Wijnen (2014-10-15 19:49:32)
Post by Bas Wijnen
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
Andreas Tille
2014-10-16 06:47:19 UTC
Permalink
Hi Bas,
Post by Bas Wijnen
Post by Andreas Tille
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.
:-)
Post by Bas Wijnen
Post by Andreas Tille
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.
Post by Bas Wijnen
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.
Post by Bas Wijnen
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.
Post by Bas Wijnen
Post by Andreas Tille
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.
Post by Bas Wijnen
Post by Andreas Tille
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.
Post by Bas Wijnen
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).
Post by Bas Wijnen
Post by Andreas Tille
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).
Post by Bas Wijnen
Post by Andreas Tille
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
Jonas Smedegaard
2014-10-16 09:40:52 UTC
Permalink
Quoting Andreas Tille (2014-10-16 08:47:19)
Post by Andreas Tille
Post by Bas Wijnen
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
Bas Wijnen
2014-10-16 18:27:37 UTC
Permalink
Hello,
Post by Andreas Tille
Post by Bas Wijnen
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.
Yes, I agree. However, sometimes the needs are so specific that it
doesn't make sense to do them on a larger scale. I'd make the packages
public, but I wouldn't suggest that a blend for very limited use
deserves a prominent position in the installer.

But as Jonas pointed out, if the blend only does the setup for running a
single application and any application can be chosen at install time,
that increases the audience to a point where it may deserve that
position.

I'll consider if I want to drive that effort. I'd really like to see
this happen, but I'm also trying to limit new projects I start, so that
I have enough time to handle the things I do properly. If more people
(besides Jonas) are interested, please let me know privately. If you
want to be the driver, definitely let me know, too. :-)

I'll send a status update by the end of the month.
Post by Andreas Tille
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.
Indeed. Someone should remember to bring them back up once that question
has been answered (and the answer has been implemented).
Post by Andreas Tille
Post by Bas Wijnen
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.
Reading that raises questions regarding the configuration editing tool I
wrote about some time ago. I'll follow up to that thread (on -devel
only).
Post by Andreas Tille
Post by Bas Wijnen
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).
Ok. Is it supposed to be possible to install more than one blend
simultaneously? Is that technically prevented with Conflicts?
Post by Andreas Tille
Post by Bas Wijnen
Post by Andreas Tille
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).
No, I'm not proud of it either. But as Feynman said: "you [yourself]
are the easiest person to fool." So I take some pride in admitting it;
telling myself otherwise would have been easier. ;-)

Thanks,
Bas
Andreas Tille
2014-10-16 20:37:51 UTC
Permalink
Hi Bas,
Post by Bas Wijnen
Ok. Is it supposed to be possible to install more than one blend
simultaneously? Is that technically prevented with Conflicts?
Not at all. I have not tested but I would bet that you can install all
existing metapackages of all Blends at the same time. Conflicts do not
make any sense to the contrary it makes sense to install say med-bio and
science-typesetting at the same time (just to say a random example).
Post by Bas Wijnen
Post by Andreas Tille
... as always with documentation. :-) The same applies to me to some
extend (and I'm not proud about this).
No, I'm not proud of it either. But as Feynman said: "you [yourself]
are the easiest person to fool." So I take some pride in admitting it;
telling myself otherwise would have been easier. ;-)
:-)

Kind regards

Andreas.
--
http://fam-tille.de
Andreas Tille
2018-08-16 08:34:36 UTC
Permalink
Hi,

to give some status information about how we can make Blends more
visible at installer stage: Holger Levsen, Phil Hands, Steve McIntyre
and I had some discussion in DebCamp. The conclusion was that adding
Blends to the installer tasksel menu would be perfectly possible if
tasksel itself would provide some menu hierarchy. We all agreed that
the current selection of tasks needs some overhaul in general. It
could provide some menu item:

"Select Blend" (or rather some better text here!)

and than you get a selection of Blends to pick (one or more) from.

For the Stretch release Phil even wrote some code in this direction that
needs some refresh. (Phil, can you give some pointer if there is
something to test?)

Any comments / code contributions are welcome.

Kind regards

Andreas.

PS: Please correct me if my short summary is incomplete.
--
http://fam-tille.de
Filippo Rusconi
2018-08-16 08:46:27 UTC
Permalink
Greetings, Andreas, and everybody,
Post by Andreas Tille
Hi,
to give some status information about how we can make Blends more
visible at installer stage: Holger Levsen, Phil Hands, Steve McIntyre
and I had some discussion in DebCamp. The conclusion was that adding
Blends to the installer tasksel menu would be perfectly possible if
tasksel itself would provide some menu hierarchy. We all agreed that
the current selection of tasks needs some overhaul in general. It
"Select Blend" (or rather some better text here!)
and than you get a selection of Blends to pick (one or more) from.
For the Stretch release Phil even wrote some code in this direction that
needs some refresh. (Phil, can you give some pointer if there is
something to test?)
Any comments / code contributions are welcome.
Please, add some small strophe to explain what a blend is, as I can tell that
this is not something widely known even to seasoned Debian users/admins (have
examples from research labs).

Also, when I installed debian-science and debichem last time, the process
downloaded such an amount of software that it almost filled my disk (which I was
not suspecting). Maybe, a rough indication of the used disk space in front of
each blend might be useful, in this respect.

Just my 2 cents, along with my very best wishes,

Filippo
--
⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁ Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄⠀⠀⠀⠀ http://msxpertsuite.org
http://www.debian.org
Ole Streicher
2018-08-16 09:30:13 UTC
Permalink
Post by Filippo Rusconi
Also, when I installed debian-science and debichem last time, the process
downloaded such an amount of software that it almost filled my disk (which I was
not suspecting). Maybe, a rough indication of the used disk space in front of
each blend might be useful, in this respect.
I would not include debian-science to the blends listed in the
installer: it is more an umbrella to organize the packages then a useful
selection of software. The software selection is also inconsitent: it
only contains software that is not maintained by a more specialized
blend (like debichem).

So, there is probably no real use case to install Debian Science in its
current form (unless someone takes the work to kurate a "Generic Debian
Science Workstation" or so).

On our last attempt, we had an opt-in for the blends to be in the
installer; I would propose the same now as well.

Cheers

Ole
Andreas Tille
2018-08-16 11:48:56 UTC
Permalink
Hi Ole,
Post by Ole Streicher
Post by Filippo Rusconi
Also, when I installed debian-science and debichem last time, the process
downloaded such an amount of software that it almost filled my disk (which I was
not suspecting). Maybe, a rough indication of the used disk space in front of
each blend might be useful, in this respect.
I would not include debian-science to the blends listed in the
installer: it is more an umbrella to organize the packages then a useful
selection of software. The software selection is also inconsitent: it
only contains software that is not maintained by a more specialized
blend (like debichem).
So, there is probably no real use case to install Debian Science in its
current form (unless someone takes the work to kurate a "Generic Debian
Science Workstation" or so).
True. There might be some general use in may be the following tasks:

https://blends.debian.org/science/tasks/dataacquisition
https://blends.debian.org/science/tasks/distributedcomputing
https://blends.debian.org/science/tasks/statistics
https://blends.debian.org/science/tasks/typesetting
https://blends.debian.org/science/tasks/viewing

(or even a subset of these). I'm not very keen on having these but may
be this could be a topic to discuss.
Post by Ole Streicher
On our last attempt, we had an opt-in for the blends to be in the
installer; I would propose the same now as well.
Definitely

Andreas.
--
http://fam-tille.de
Andreas Tille
2018-12-03 21:32:28 UTC
Permalink
Hi,

somehow I've thought I would have pinged about this one and I even
somehow remember that Holger liked that I did so but I do not find and
trace of this in my outbox nor the mailing list archive. So may be I
have dreamed this. It would be a real dream if we could finally realise
this 15 year old idea to have Blends right in the installer. Is there
any work in progress that could be tested?

Kind regards

Andreas.
Post by Andreas Tille
Hi,
to give some status information about how we can make Blends more
visible at installer stage: Holger Levsen, Phil Hands, Steve McIntyre
and I had some discussion in DebCamp. The conclusion was that adding
Blends to the installer tasksel menu would be perfectly possible if
tasksel itself would provide some menu hierarchy. We all agreed that
the current selection of tasks needs some overhaul in general. It
"Select Blend" (or rather some better text here!)
and than you get a selection of Blends to pick (one or more) from.
For the Stretch release Phil even wrote some code in this direction that
needs some refresh. (Phil, can you give some pointer if there is
something to test?)
Any comments / code contributions are welcome.
Kind regards
Andreas.
PS: Please correct me if my short summary is incomplete.
--
http://fam-tille.de
--
http://fam-tille.de
Continue reading on narkive:
Loading...