Re: Enterprise and Debian Pure Blends
On Fri, Aug 06, 2010 at 12:19:11AM +0200, Andreas Tille wrote:
> 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]
It doesn't take long to find. Still the problem to find software for
the purpose remains: In this example, it's cutting commercials out of
movies. I'd prefer to do that automatically, but I haven't found a
way, so I'm using dvbcut. Now read the description of dvbcut:
"DVBCUT is a Qt application that allows you to select certain parts of
an MPEG transport stream (as received via Digital Video Broadcasting,
DVB) and save these parts into a single MPEG output file. It follows a
`keyhole surgery'' approach where the input video and audio data is
mostly kept unchanged, and only very few frames at the beginning
and/or end of the selected range are re-encoded in order to obtain a
valid MPEG file."
If you were searching for software to cut commercials out of movies,
would you somehow get the idea to search for software that "allows you
to select certain parts of an MPEG transport stream [...] and save
these parts into a single MPEG output file"? I never would.
> 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.
Hm, I installed it with aptitude. It's probably on debian-multimedia,
I don't know.
> 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.
In theory yes, but practically, I'm not sure. When you, for example,
take a look at the categories they have on sourceforge.net and pretend
they represent tasks or metapackages, how much do they actually help
you finding software for a particular purpose? You usually end up with
so many pages of results to your search strings that you can't read
them all and might very well miss what you're looking for.
So how would listing all the software that isn't available as a Debian
package on those web pages as well really help with finding software
for a particular purpose?
> 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.
What is UDD?
> If you like to see this - why aren't you looking at the tasks pages
> which even provide *translated* descriptions, screenshots and more?
Because I didn't know that there were such webpages and because I'm
using aptitude and apt-cache search or google or sourceforge ...
> So whoms fault is it that there is no such list? Did you ever heard
> about the Do-O-cracy principle inside Debian.
Did you ever notice the huge Keep-away-O-cracy they have? Try to
provide a Debian package, and you are totally overwhelmed with tons of
documentation to read and lengthy preliminaries and whatnot before you
could do anything. You just figure your package isn't that important
and give up ...
> 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.
I have no idea how to do whatever it is and what to do. I'm only
saying that finding software can be a problem and questioning that
providing metapackages or tasks does help all that much.
> > 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.
Still the problem remains: How do you find software for a particular
task? I'm afraid the longer the lists get, the less useful they might
become. Once they're long enough, it's like searching for something on
sourceforge or using apt-cache search or google ...
> > 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.
That's what I mean: Software might be easier to find if there was more
detailed information available right away and if one could search for
what he's looking for --- like software that's useful to cut out
commercials (automatically) or an imap server supporting maildir or a
groupware solution that comes with a web-chat. Providing the same
information which is already available in another format isn't so
helpful.
> 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.
How about a wiki? Make a page for each package, and ppl can easily add
information without having to read lots of documentation.
> > 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.
Or you didn't explain very well what you were talking about.
> 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.
It might help to make them known to users and make them available in
aptitude and the installer. If they were readily available for
browsing rather than on a website ppl don't know about, users could
make more use of them.
Reply to: