(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 _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
