Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
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
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.
> 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.