Re: Enterprise and Debian Pure Blends
On Wed, Aug 04, 2010 at 09:03:28PM +0200, lee wrote:
> It would be nice if it was easier to browse by groups with
> aptitude. Aptitude is horrible ...
Well, the idea of metapackages was to *circumvent* browsing with
aptitude at all and just teach people to install the metapackage.
It is somehow turning the knowledge of the Blend maintainer into
a recipe: Just install metapackage X and you are ready (you might
use apt-get or any other interface).
> >From my point of view, the problem is to find out what software is
> available for something you want to do. Even if you you could look at
> packages at a group level, you'd still need to look at every single
> package in a group --- or in several groups --- to see if it can be
> useful for what you want to do.
That's why I promote the tasks pages. They provide all information (in
the best case in your language) and you can browse the group which will
be installed when installing the metapackage. The advantage to have
it online is that you can even show this your colleague who does not
even need to have a running Debian (-derivative).
> Since there are so many packages, that
> leaves you with apt-cache search [something] | grep | less, google and
> sites like freshmeat.net and sourceforge.
Preparing a reasonable set of packages is much safer against both false
positives in the search as well as missing packages. The apt-cache
search | grep approach does not lead that far.
> In the end, with finding
> software what counts it's your knowledge (to a great deal from
> browsing that long package list and reading the descriptions), your
> experience with finding what you need and your good or bad luck with
> using the right keywords in your searches.
This exactly is what we want to prevent and we are targeting at users
who just do not have this knowledge in the first place nor will find the
time to read all this stuff. Back to the topic enterprise: In this
specific case I assume that this is not a big deal for admins in
enterprises because I expect those people to know the packages they want
to use in the first place. Here I would rather expect that the aspect
of making package groups working together by reasonable configuration
is in the main focus.
> Having that said, I wish many, if not most, of the package
> descriptions would tell you some more about the software, saving you
> having to install it to read the documentation and to try it out to
> find out if this software happens to have just that particular feature
> or functionality you're after. It doesn't at all matter into which
> group someone put that software.
Well, if you find broken individual package descriptions there is no
better solution than filing a bug report against this package. At least
the tasks pages provide a link to the homepage of the project which
might contain better information.
> So after all, what's the use of groups?
Counterquestion: Do you think you will find relevant packages better
without having groups for certain tasks?
If the groups are properly designed they lead you quite directly to a
reasonably sized set of packages where you really can read the
descriptions. But it is not only about *selecting* packages. This can
also be done by properly designed DebTags (and in fact I try to find
means for better DebTag integration). The tasks approach enables also
levels in form of Recommends or Suggests - so we can express preferences.
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. The same feeling has
leaded us to find some kind of a solution to this problem (perhaps we
are only half way done, but anyway there are people out there which are
really happy).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: