Re: Enterprise and Debian Pure Blends
On Wed, Aug 04, 2010 at 10:20:08PM +0200, Andre0;261;0cas Tille wrote:
> 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).
Hm, I've seen them as a way to make sure that the software which is
actually needed to get something to work is being installed --- not as
a way to provide a collection of software that might be useful for a
task.
The point remains that one needs to know which software to use for a
task, and installing a metapackage doesn't tell one what software to
use. But when you know what software to use, you can install the
particular package --- be it a metapackage or not.
> 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).
I don't know how to browse groups. Metapackages tell you what they
depend upon if you care to look, but that's not the way I'm using
them. As said above, I've always seen them as a way to make sure that
what is actually needed to get a parcticular software to work is being
installed, eventually with extended options.
> > 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.
Dependencies are what prevents missing packages. False positives,
well, if you could tell apt-cache to search only metapackages, you
might be able to reduce the number of false positives, but by
excluding everything else, you'd probably end up excluding the package
you're looking for from the search and never find it. Since you can't
tell apt-cache (or can you?) to search metapackages exclusively, they
contribute to finding more false positives.
And no, I don't want the metapackage unless it's purpose it to make
sure that what is actually needed is installed because I don't want
unwanted software. That should already be provided by dependencies.
> > 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.
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?
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. 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.
But that could help me finding software useful to me. Just installing
some metapackages isn't useful at all.
> 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.
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.
> 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.
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.
> > 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?
They won't be easier or more diffucult to find because I can't browse
the groups anyway. Aptitude is horrible ...
If I could browse groups --- or metapackages --- it could be easier to
find relevant packages. But when I'm looking for a MUA that supports
maildir, browsing a group or a metapackage that indicates MUAs is only
so helpful when the descriptions of the packages do not tell me if the
MUA supports maildir or if I can use emacs or xemacs as an editor to
write mails.
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.
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?
That's just an example for what I mean when I'm saying that the
problem is finding the software I need. The question is not wheather
groups or metapackages would make it easier or not to find relevant
packages. The package descriptions and what means you have to search
them are crucial.
>OB 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.
Yes, that is useful when I don't exactly know what I'm looking
for. If I didn't know about IMAP, for example, I'd not be looking for
it, but while reading package descriptions, I might learn about it.
> 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. 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.
> 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).
There's aptitude ... not supporting the browsing of metapackages or
groups, or if it does, I haven't found out how to do that. I'm lucky
to be able to use it to install and to remove packages, and I hate
aptitude. Sometimes you need to somehow circumvent it because it
becomes even more, and totally, confusing and thus useless when there
are problems with dependencies. Dselect was a lot easier, though not
better suited for what you have in mind.
So one thing to work on is package descriptions, another is something
better than aptitude that would enable users to actually make use of
groups and metapackages.
Reply to: