Re: Enterprise and Debian Pure Blends
On Thu, Aug 12, 2010 at 04:38:44PM +0200, lee wrote:
> 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:
>
> ...
>
> 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.
What does it have to do with your critics at the concept of assembling
all such packages in certain tasks? If you have a problem with a
specific package description you should probably file a bug report about
this. I doubt that reportbug will work against packages from
debian-multimedia.org - but anyway, dropping the maintainer a note about
this with a suggested better description will probably fix this.
> > 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.
Yes it is.
> > 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?
We are not discussing about SourceForge here. We are discussing about
adding some structure in the basically unstructured pool of Debian
packages.
> 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?
Better design of the tasks to make them useful enough to not show this
SourceForge feature?
> What is UDD?
http://wiki.debian.org/UltimateDebianDatabase
The tasks pages are created from the information in 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 you don't know these pages but are constantly arguing that they
are not helpfull. That's interesting.
> > 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'm sorry there is a proof that there are people who managed this (if
not we would not have such a lot of packages). If you find the right
team you will probably guided through your newbee problems - at least
this is the case in those teams I'm part of. Moreover Debian is not
only about packaging: It is also about reporting and fixing bugs by
patches (see above - provide better descriptions), writing better docs
if you have problems with them etc.
> 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
Yes.
> and questioning that
> providing metapackages or tasks does help all that much.
But questioning something without knowing about this does not sound
convincing to me, sorry.
> 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 ...
The solution is a better design for the task, looking at popcon stats
might help as well, having a screenshot comes handy, etc. For several
cases it works quite good, there are counter examples as well that's
correct.
> 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.
Have you ever heard about DebTags? They try to enable a semantic
search. That's probably something for you (they need supporters!). I'm
looking for ways to connect DebTags better into the Blends stuff.
> How about a wiki? Make a page for each package, and ppl can easily add
> information without having to read lots of documentation.
What is preventing you from using a Wiki?
BTW, we tried maintaining a Wiki about packages and we terribly failed
in terms of keeping it up to date. The weak part in "ppl can easily add
information" is the term *can* - they just do it once or twice and than
the Wiki starts bit rotting. Feel free to prove me wrong in this but
we just learned that the only way to get up to date information is to
assemble the information automatically.
> > 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.
This might be, but please excuse me: I spended days to write some docs
and do not want to repeat my doc in random mails.
> > 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.
Well, this is my last answer to you in this thread because I admit I'm
really bored. You are refusing to read the docs where the existing
metapackages are described. There are other ways to find out what
metapackages exist. The thread started with my suggestion to create
metapackages for Debian Enterprise - you told me this would not help and
now you are lamenting that they do not exist. I do not feel my time
well spend in running circles in arguing.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: