[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Please Improve Debian for Multimedia Production

On Mon, 23 Mar 2009, Felipe Sateler wrote:

The DeMuDi project is dead AFAIK.

This fits to my observation.

The 64studio spawned from it, and can't be a
pure blend. Actually the demudi team merged with the Debian Multimedia
Maintainers, so we now work together.

That's really good.

I would suggest removing it from the
blends list (although the section on why demudi/64studio couldn't be a blend is
useful to highlight that blends are _in_ Debian).

I'd suggest to keep it for some while there for the purpose you mentioned
except if there is some new effort taking over the role of a Blend (see below).

There is an effort to support multimedia, a merge of the 2 previous efforts.

This is really godd news and gives some hope.

After reading the documentation, I still don't know if a blend is useful for us.
Blends seem to be some kind of cooler tasks, is that true?

Well, the terminology was taken over from tasksel at some former point
in time - but it is a little bit more.

For them to be
really useful there should be clearly defined use cases that justify creating
the metapackages and tasks, for which I'm afraid there aren't in the multimedia
world. Other than ardour or audacity, every multimedia user will probably use a
different set of tools for doing their work (ie, there are lots of alternative
software synthesizers/effects processors/whatever). If there is no such clear
set of tools, is there a point in creating a blend?

I'm not sure whether your point of view is based on your large amount of
knowledge you might have about this field.  You definitely know what to use
and where to look at.  Assume a person who is installing Debian the first
time.  Which advise would you give if this person might ask you: What
Multimedia software is inside Debian.  What should I install for a start.
Which applications should I try to find out which might fit my needs best?

I can not imagine that multimedia is that different from other Blends.  Look
at the Debian Med biology task: There are more than 60 Dependencies inside
Debian and there is not a single user who is using them all.  We sometimes
consider to split this up to some extend but did not until now.  The fact is
if a biologists asks you:  What biological software is inside Debian? You can
simply answer: Lock here:


What should I install to get ready for work quickly?

    apt-get install med-bio

For sure this installs several applications which are not needed by every
person - but this is no exception to any other method to install a group
of software.  Metapackages are builded that way that you can deinstall
every application because it uses only Recommends.  So the user can start,
try and in case of get bored by something remove a package later.

Blends are intending to give the flat package pool some user specific
structure which regards the needs of a certain group of users.  And you
as the multimedia developers are the people who know these users and
might be able to prepare the system as good as possible.  I might imagine
certain tasks (please be patient - it is a suggestion of a poor user
regarding multimedia stuff, just correct me if I'm wrong about your

   note-editors  (for noteedit - no idea whether this is a reasonable category name)

Probably syncing with existing DebTags (I did not checked these) should
be a good advise.  Probably more fine graining needs to be done.

At least I would *really* love to have an overview about these categories
in Debian.  Technically you might also approach this by applying DebTags
and my goal is to technically merge DebTags and Blends technique stronger
in the future.  But as far as I know there is no such thing like a tasks
or a bugs overview based on DebTags.  Moreover you are able to include
packages into your focus which are maintained by maintainers who are not
joining your Multimedia Team (for whatever reason).

I hope I was able to give some reasons why a Blend makes sense.

Kind regards



Reply to: