Maintaining tasks files

[Reinhard Tartler]

(CC'ing you, as I know that you are currently travelling)

On Mon, Aug 16, 2010 at 09:42:04 (CEST), Andreas Tille wrote:

> On Fri, Aug 13, 2010 at 07:32:38PM +0200, Reinhard Tartler wrote:
>> On Fri, Aug 13, 2010 at 17:46:18 (CEST), Felipe Sateler wrote:
>> > On 13/08/10 10:57, Reinhard Tartler wrote:
>> >> On Fri, Aug 13, 2010 at 09:49:01 (CEST), Andreas Tille wrote:
>> >> Well, I think defining these tasks is not easy at all. AFAIUI, the user
>> >> is expected to select a task and then *all* packages included in the
>> >> task is going to be installed.
>
> Not necessarily.  In the tasks files you can specify also alternatives
> like in any debian/control file.  At first you should define a target
> group of users.  It makes no sense to try to prepare one task file for
> 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?

> There is no need to install a lot of applications on one machine.  The
> blends-dev tools are building a tasksel control file which really would
> install everything in the task.  This was used by Debian Edu and the
> functionality is keept - but there is no need to really use tasksel
> (even if the name "tasks" is inspired by tasksel).  In Debian Med and
> Debian Jr. the usage of metapackages is prefered and there you have on
> one hand the alternatives option for instance
>
>    Depends: mplayer | xine-ui | ffmpeg
>
> 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?

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?

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?

If I get that correctly, this sounds pretty useful to me!

> While nobody will force you to finally create those metapackages I
> personally do not see a reason why they should not be provided.  The
> Debian Multimedia beginner would be really happy about such packages -
> at least I would definitely - even if I would end up with some
> applications I will finally not use.  (How many packages on a typical
> Debian machine will not be used - my rough estimation is close to 50%.)
> Moreower the metapackages do not use hard "Depends" but rather
> "Recommends" and thus the user is free to purge some packages afterwards
> anyway.

Interesting.  Just curious, did you have a look at the
'ubuntustudio-meta' source package?

http://packages.ubuntu.com/source/lucid/ubuntustudio-meta.

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?

>> >> However, in our multimedia land, we have
>> >> both 'consumer' multimedia libraries like codecs, drivers, media
>> >> players, and software for multimedia producers. For both areas, we have
>> >> several similar software package that users most likely want to select
>> >> alternatively, very seldomly together.
>
> As I tried to explain above this is perfectly possible.  Moreover we
> could design tasks like
>
>    multimedia-prof-<task1>
>    multimedia-consumer-<task1>
>
> to make a clear difference here.

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.


> In a similar discussion on Debian Accessibility[1] I mentioned the
> option of letting the user select via debconf the default application
> (say videoplayer) out of the alternatives used.  You can store the
> answer for instance in
>
>    /etc/default/multimedia-videoplayer
>
> as
>
>    VIDEOPLAYER=<selected_player>
>
> and can install a
>
>    /usr/bin/videoplayer
>
> script which regards this setting.

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.

>   This can be easily approached by some extra workload of the
> metapackage which is perfectly handled by the blends-dev build
> mechanism which is featuring full config, {post,pre}{inst,rm} features
> for each metapackage as well as it handles extra files (like
> /usr/bin/videoplayer).  In short: Metapackages in the Blends scope are
> more clever than just carrying dependencys stupidly.

I see. Well, I'm still not absolutely sold that metapackages are the
correct conceptunal answer to the problem at hand, but I also have to
admit, that I didn't understand the problem itself fully. I'll have to
think more about it, and probably play a bit with blends-dev.

> BTW, if time permits I might also include packages which currently are
> only in forks on the tasks page as separate section. We currently have
> the "inofficial packages" section on the tasks pages, but we also have
> information about Ubuntu in UDD and I could query some content from
> there. 

About what content are you thinking of at this point?

> 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.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4