Bug#825186: Please which tasks should be installed at a default installation of the blend

[Jonas Smedegaard]

Quoting Ross Gammon (2016-09-10 09:18:16)
> On 06/06/2016 03:19 PM, IOhannes m zmölnig (Debian/GNU) wrote:
>> On 05/27/2016 10:06 PM, Ross Gammon wrote:
>>> Maybe we just install the lot (except devel) for Stretch, and aim 
>>> for a more fine-grained method for Buster?
>> 
>> so it seems like you went for that option.
>> that's certainly the easiest route from *our* perspective.
>
> Yes - I thought it was worth getting something into the installer for 
> the alpha releases, so people can have a play. There is still time to 
> do something more fine-grained.

Agreed.

>> i think most (all?) tasks we currently have, aggregate packages with 
>> similar functionality (e.g. installing "recording" will give you 
>> virtually all debian packages that can record media content); however 
>> i believe that in practice, people will only need a single package 
>> that does the job (e.g. i want to record audio - give me any package 
>> from "recording" but not all of them).
>> 
>> so the idea i tried to express in my last email was to basically 
>> create a *new* task "multimedia-minimal" (or "multimedia-handpicked" 
>> or whatever), that contains a selection of packages for various 
>> tasks, but probably no more than 2 packages for any specific task.
>> 
>> but of course this requires a lot more work (and as of know, it's 
>> mainly ross who maintains the multimedia-tasks).
>
> Yes - it just remains to select those packages. I would like to have a 
> multimedia-minimal package that just has 10 or so essential packages 
> to get started with audio/music creation or video creation/editing. Or 
> maybe separate audio-minimal and video-minimal packages, so that they 
> can be recommended by the audio & video tasks.

For consumer tools, I suspect that "minimal" offerings are better 
addressed - and done already - by the various desktop teams.

For production tools, I believe there is little sense in "minimal": We 
need "stacks" covering different styles of production.


>> related but not the same issue: i wonder whether it is possible to 
>> stack tasks (e.g. have a "csound", "puredata" and "supercollider" 
>> tasks, and then have a single "computermusic-languages" task that 
>> just depends on the sub-tasks).
>
> I spotted that you went forward with this suggestion (or something 
> based on it). Excellent! I almost did something like that, but I 
> wasn't sure of the categorisations (and couldn't think of a good name 
> for the umbrella task), and never got around to asking on the list.
> 
> By the way, feel free to do an upload of this latest Blend status (if 
> you have a spare timeslot). It will need to pass through the NEW 
> queue.

Our current metapackages one-dimensionally track _kinds_ of tools.

I suggest we instead track two dimensions at a time: Each metapackage 
covers some _other_ dimension than the kind of tool, with each 
recommendation being a group of alternative packages of some kind.

That way our bias in curating packages is limited to which package is 
listed first (i.e. gets installed if nothing else favors another 
alternative), not what will always get pulled in.

Examples covering MPD (fully) and video players (partly):

multimedia-framework-vlc:
 * vlc
 * phonon-backend-vlc
 * libreoffice-avmedia-backend-vlc
 * browser-plugin-vlc

multimedia-framework-gstreamer:
 * gstreamer1.0-tools
 * phonon-backend-gstreamer
 * libreoffice-avmedia-backend-gstreamer

multimedia-framework-mpd:
 * mpd | mopidy | groovebasin | beets | forked-daapd (server)
 * gmpc | mpc | glurp | mpdcon.app | qmpdclient | ario | sonata
   | cantata | gbemol | gimmix | xfce4-mpc-plugin (user interface)
 * mpdris2 (MPRIS2 client)
 * g15mpd (g15daemon client)
 * gkrellm-gkrellmpc (GKrellM client)
 * mpd-sima (auto-dj feature)
 * mpdscribble | mpdcron (publish feature)
 * mpdtoys
 * mpdcron

multimedia-consume-gtk:
 * gnome-mpv (video player)
 * gnome-mpv (youtube client)
 * gmpc | ario | sonata | gbemol | gimmix (MPD client)

multimedia-consume-qt:
 * smplayer | vlc (video player)
 * smtube | minitube (youtube client)
 * cantata | qmpdclient (MPD client)

multimedia-consume-gnome:
 * gnome-mpv | totem (video player)
 * gnome-mpv | totem (youtube client)
 * gmpc | ario | sonata | gbemol | gimmix (MPD client)

multimedia-consume-kde:
 * kmplayer | kaffeine (video player)
 * cantata | qmpdclient (MPD client)

multimedia-consume-terminal:
 * mps-youtube | youtube-dl | get-flash-videos | cclive | quvi
   (youtube client)
 * ncmpcpp | ncmpc | pms | draai | mpc (MPD client)

multimedia-consume-web:
 * mopidy | groovebasin | fookebox | ampache (MPD client)

multimedia-consume-services:
 * mpd | mopidy | groovebasin | beets | forked-daapd (MPD protocol)
 * mpdris2 (MPRIS2 protocol)
 * mpd-sima (MPD auto-dj feature)
 * mpdscribble | mpdcron (MPD publish feature)


The heavier (-gnome and -kde) multimedia-consume-* packages above 
include and favor lighter tools - i.e. for each group...:

 a) If no UI-optimized tools exist then the group of the underlying 
    toolkit (-gtk or -qt) is used in full.
 b) If UI-optimized tools exist but only ones bound to heavier
    frameworks (vlc or gstreamer) then one non-UI-optimized tool
    is included and favored.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160910/0decbc09/attachment-0001.sig>