Re: Enterprise and Debian Pure Blends
On Fri, Aug 13, 2010 at 10:21:57AM +0200, Andreas Tille wrote:
> 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?
It is an example to show how it can be difficult to find software,
metapackages or tasks or not. If it's not the purpose of your
metapackages and tasks to make finding software easier, then what I'm
saying is pointless.
> > > 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.
It is an example demonstrating the results of an attempt to bring some
structure about a genuinly unstructured pool of sotware. One can learn
from examples.
> > 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?
Which is something you don't want to discuss ...
> > 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.
Can you read? I said "I didn't know".
> > > 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).
So? Did I say it's impossible?
> 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.
I don't know about teams.
> 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.
Which is something we're not discussing here ...
> > 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.
Guess what, I took some looks at those webpages listing the software.
> 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.
sounds good
> > > 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.
Just don't expect ppl to go to lengths to read lots of external
documentation when sending emails to mailing lists. It's more helpful
to make clear what you're talking about in your email, without readers
having to switch to a webbrowser or some other software to eventually
figure out after a few hours what you're trying to say.
> > > 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.
Learn to read first ... I didn't say the packages don't exist.
Anyway, you're convinced that these packages are a great thing and not
open for suggestions or discussions on how they could be improved to
be actually helpful, and you don't want to consider the practical
experience users make when trying to find software. When considering
the users and the usefulness of your doing bores you, what are you
creating these packages for?
Reply to: