Maintaining tasks files

[Andreas Tille]

On Tue, Aug 17, 2010 at 06:29:11PM +0200, Reinhard Tartler wrote:
> > several user groups.  If there are applications which are useful for
> > more groups just list the application in question for all of them.
> 
> Interesting. Is there some easy way to query in what tasks a given
> package is used?

I'm just using grep on the tasks files in SVN.  IMHO for developers this
is OK.  Do you have any other purpose in mind?
 
> > is fullfilled if only one of them is installed as well as if you can
> > also use
> >
> >    Suggests: <not so important package>
> >
> > which IMHO are two important advantages over the tasksel approach.
> 
> At what time are these metapackages used/installed? After tasksel in the
> installer?  Instead of tasksel?

I tried to enable selection of Blends tasks immediately after
installation (see bug #186085) but failed.  So for the moment
you just install the metapackages as any other package with
your favourite package management tool.
 
> Let's imagine the following depends in the 'multimedia-consumer'
> metapackage:
> 
> Depends: mplayer | gxine | totem | kaffeine | dragonplayer | vlc
> 
> I guess that if we the user first selects to install an KDE system in
> tasksel in d-i, and in that task kaffeine (or dragonplayer, not sure
> what the current default media player is) is installed, the
> 'multimedia-consumer' metapackage will not install any other media
> player, correct?

Yes (but untested).
 
> Assuming that an 'LXDE' task does not install any media player and is
> selected first in the installer, does the 'multimedia-consumer'
> metapackage only install mplayer and nothing else?

Yes (also untested).
 
> If I get that correctly, this sounds pretty useful to me!

If apt works as I expect it to work than this is exactly the case.

> Interesting.  Just curious, did you have a look at the
> 'ubuntustudio-meta' source package?
> 
> http://packages.ubuntu.com/source/lucid/ubuntustudio-meta.

I should do this later.
 
> It's implementation might be different (it uses germinate), but it seems
> to me that blends-dev and germinate/ubuntustudio-meta share very similar
> goals, right? I imagine that we could use that at least as source of
> inspiration what multimedia tasks would be useful for a DeMuDi Blend.
> 
> 
> BTW, do Blends provide their own, customized installation media? What
> about live CDs?

We should probably make a FAQ about this.  The answer is: There *should*
be a script to simplify this but probably it does not exist yet.
Somebody has prepared something for Debian Med at

  svn://svn.debian.org/svn/debian-med/trunk/community/infrastructure/livecd

In principle metapackages make the lice CD preparation quite simple by
using live-helper but I would be really happy if somebody would write
a generalised script + configured hooks which just needs a

   blend-build-livecd <blendname>

and similar with to build d-i images.  It's just a matter of finding the
nneded time to do this, but in principle it should not be that hard.
 
> For comparison, ubuntustudio-meta in lucid creates these metapackages:
> 
> $ grep -E ^Package debian/control
> Package: ubuntustudio-desktop
> Package: ubuntustudio-audio
> Package: ubuntustudio-graphics
> Package: ubuntustudio-audio-plugins
> Package: ubuntustudio-video
> Package: ubuntustudio-font-meta
> 
> So this matches your suggestion pretty closely.

Perhaps somebody could browse the list and adapt our tasks.
 
> I see. Well, I think we'd first need to get an idea what kinds of
> configuration options would be interesting for a DeMuDi Blend, but it's
> great to know that we have a place for this.

:-)
 
> About what content are you thinking of at this point?

Multimedia related packages which are in Ubuntu or debian-multimedia.org
but not (yet) in Debian.  I guess there are some of them, but I'm not
that deeply involved in this field.
 
> > Thinking further in this direction we could think about adding
> > Debian-Multimedia.org package information to UDD and add this to the
> > tasks page.
> 
> Well, with the experiences we've made so far from bug reports, I don't
> think that we can endorse using that archive with good conscience.

Well, we are not really *using* this but we are providing information
about packages which can be used in principle by our users (they do it
anyway).  Moreover it saves us some work to maintain the metainformation
about potentially interesting packages for our users in the tasks files
explicitely.  (This probably needs some detailed demonstration and is
hard to explain in a short mail.)

Kind regards

     Andreas. 

-- 
http://fam-tille.de