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. (As
I explained on other lists several times: We do NOT try to approach a
classification where one package just fits in one category. That's not
helpful from the user perspective. A user should identify himself with
one (or more) tasks and should find there applications which are useful
to do this task.)
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.
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.
> >> 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.
> >> The 'best' selection of packages
> >> depend of course on the exact requirements of the user, but most likely,
> >> it will not be the full set of available packages.
But we need to propagate to the user what actually *is* the full set to
enable him deciding what he wants to select. Some reasonable
classification (prof/consumer) might help here and as I said there is no
real harm done if for the first shot some more applications than finally
are used will be installed. (Well, I *personally* do not want this on
*my* computer - but I guess we as developers think a bit differently
than users who are just diving into this, right.)
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. 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.
> >> Andreas, can you perhaps elaborate on your(?) / the idea about these
> >> tasks files and where are they maintained in Debian? The tasksel package
> >> or somewhere more decentrally?
I personally do not like the tasksel usage even if the Blends tools are
supporting its use.
> > As the person who encouraged Andreas to take the Blends thing here, I
> > must say that I was definitely not thinking about tasksel-style tasks,
> > but rather at the pages he showed during your Debconf talk. Those tasks
> > can list all relevant software, and then the user can choose which ones
> > to install, because there is no direct interface between tasks and apt.
> > In other words, I'm more interested in the display/marketing potential
> > of the web site than on the usefulness of tasksel-style tasks.
> >
> > Also, they are maintained in the blends svn repository
> > http://svn.debian.org/wsvn/blends/projects/multimedia/trunk/debian-multimedia/tasks
>
> Oh, interesting. these files look very interesting. I definitly need to
> look more closely how they are supposed to be used and what we can use
> it for.
Feel free to ask in case something remains unclear. Depending on the
kind of question I will at least CC debian-ble...@l.d.o - some details
might perhaps even off topic on pkg-multimedia.
> BTW, do we have UbuntuStudio folks here? Would a channeling of your work
> in a Debian Multimedia Blend be beneficial to you?
I do not see any reason why any fork of Debian should not use the Blends
stuff. That's also a reason why I propagate those metapackage building
source packages using blends-dev - it makes propagation to forks more
visible. 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. Thinking further in this direction we could think
about adding Debian-Multimedia.org package information to UDD and add
this to the tasks page.
Kind regards
Andreas.
[1] http://lists.debian.org/debian-accessibility/2010/07/msg00025.html
--
http://fam-tille.de
_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
