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

Re: Enterprise and Debian Pure Blends



On Thu, Aug 05, 2010 at 03:46:12PM +0200, lee wrote:
> 
> But that doesn't make it unnecessary to read package descriptions. For
> example, if someone wants to cut commercials out of movies he has
> recorded with his TV card, he might find dvbcut very useful. That
> requires him to somehow find out that there's dvbcut. Metapackages or
> not, how is he supposed to find out?

And if there would be a Debian Multimedia Blend working for multimedia
issues he yould have a look.  I'll tell you some secret: Because I hate
looking for multimedia applications I just started working on such a
thing without making some noise about it because it is far from ready.
Just have a look at

  http://blends.alioth.debian.org/multimedia/tasks/

I'm curious how long you will need to find dvbcut.  If you miss some
other stuff there - it's in SVN[1]

I hope you have noticed that dvbcut is not mentioned in the "green" area
of official packages.  That's for the reason because dvbcut is no
official Debian package.  I hope you like the concept of so called
prospective packages which also lists packages which are not (yet) in
Debian.  BTW, the metapackage would suggest those not official packages.

There would be an option to move content of debian-multimedia.org (and
other add ons) into UDD which would much more convenient to work with
those dependencies.  But I might like to stress the fact that in this
case we are not talking about a PURE Blend any more (which consists
of pure Debian only).  Any volunteer to import package information from
debian-multimedia.org into UDD?

> Then what I would like to see is a list of metapackages and the
> packages they install and their descriptions like:
> 
> 
> Metapackage foo --- Description
>    - package asfasdf --- Description ...
>    - package werwirw --- Description ...
>    ...
> Metapackage bar --- Description
>    - package vm,cvxc --- Description ...
>    ...
> ...
> 
> 
> ... and be able to browse through the list.

If you like to see this - why aren't you looking at the tasks pages
which even provide *translated* descriptions, screenshots and more?

> Now if there was a
> metapackage indicating software useful when one has a TV card, I could
> take a look at the packages indicated and pick the ones that I think I
> could use. I still wouldn't want to install the metapackage because I
> don't want all the packages it indicates.

Nobody forces you to install the metapackage - but those who want it can
just do it.  The point is that the metapackage and the list you are
asking fore are generated from the very same source.
 
> Well, think about the groupware example: If there was a metapackage
> --- or group --- that one could browse, indicating packages related to
> groupware, it would make it easier to find the useful packages. The
> admin doesn't necessarily know what groupware solutions are available,
> so he needs to find out if he's to provide some kind of groupware.

So whoms fault is it that there is no such list?  Did you ever heard
about the Do-O-cracy principle inside Debian.  I provided the technique
which turns a list of dependencies into the list you want to read.
Would you care for starting with debian-enterprise groupware task
under

   svn://svn.debian.org/svn/blends/projects/education/trunk/debian-education/tasks

?  Just show me the code to make me believe your intent is honest.
 
> Oh it's not that a description needs to be broken to not tell you if a
> software does have a particular feature or not. For example, when you
> look at the description for evolution, you probably won't say the
> description is broken. But the description doesn't tell you if
> evolution supports maildir.

For those details there is a link to the Homepage of the package
on the tasks pages.
 
> They won't be easier or more diffucult to find because I can't browse
> the groups anyway. Aptitude is horrible ...

So if you did not found my answer to this read again what I wrote in
this and the previous mail.
 
> It's about finding software. I'm wondering atm which imap
> daemon/server supports maildir. How do you find that out? An
> "apt-cache search imap" yields 220 packages. "apt-cache search imap |
> grep maildir" yields only 6. The only one that appears suitable is
> dovecot-imapd, but the description says "Dovecot is a mail server
> [...]". Well, I'm using exim4 and don't want another MTA, and cyrus is
> overkill (and doesn't support maildir) because in this case, I have
> only one user I need this solution for.

Probably somebody has to provide this information in a tasks file.
There are several options to add it.
 
> Now what? Is there a metapackage that would help me to find what I'm
> looking for? Read the descriptions of 220 packages, try out 100 or so,
> to find out if this software does what I need? Experience tells me
> that it would very likely lead to nothing but wasting my
> time. Alternatives? A webmail client that supports maildir --- but
> "apt-cache search webmail | grep maildir" doesn't find anything at
> all. Now what?

Read the BLends doc.  Mind the "Remark" field inside the tasks files.
Create a task file with remarks.  Render the tasks pages.
It needs just somebody who does the job to provide the information -
the technique for publishing it is there.
 
> That's just an example for what I mean when I'm saying that the

If your example was intended as a counter example against Blends you
definitely failed but rather have proven that you did not dived into the
docs but rather did some speculation what might be there and what not.
 
> > Question:  How much time have you spended to browse those tasks pages I
> > have linked to in my first mail?  I somehow have the impression that you
> > rather was reporting about your frustration.
> 
> Hm, I didn't even notice that you linked pages.

Assume I provided the links for a reason ...

> It's not about
> frustration with something. My point is that finding the software one
> is looking for is the problem and that just installing some
> metapackages isn't a solution at all. Metapackages or tasks haven't
> changed the ways of finding software.

If you don't like the metapackages nobody will force you to use them,
right.  As I said the power of metapackages is probably underestimated
but I will not fight a flameware about this.

Kind regards

     Andreas.
 

[1] svn://svn.debian.org/svn/blends/projects/multimedia/trunk/debian-multimedia/tasks

-- 
http://fam-tille.de


Reply to: