Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
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
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 and countless
talks as well as trying to push newcomers into the topic by
sponsering their packages.
> 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 (as advised in my last mail) you not only get
an idea about how we form teams but about the Blends concept in
> 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.
That's always needed.
> Examples of the target audience would be useful.
Hmmmm. I had thought / hoped that this is documented in.
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 ) and for scientists (task list of Debian Science )
I'm working surrounded by biologists and epidemiologists and I'm just
pointing my (non-Linux using!) colleagues frequently to the according
tasks pages ( resp. ) 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
> > > > 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
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
Hope this additional explanation helps
... or instead of spending time into the full video you rather might
like to simply browse the subtitles starting at line 2379