Re: problems of normal user
Andreas Tille wrote:
On Wed, 18 Oct 2006, Petr Houska wrote:
first of all, please be patient with me, because this is my very
first post to such a mailing list.
Hi Petr, thanks for your input.
Today I tried to install some of the med-* packages and got very
confused during the process.
Great that you gave them a try - shame on us that we confused you.
But we
are working on this. ;-)
The information I was looking for was hidden deep in
/usr/share/doc/med-* directories
It is probably our fault to assume that users are comfortable to
always look
into /usr/share/doc/<packagename>. While it is allways my first thing I
do after installing a new package to have at least a quick glance into
this directory I admit that at least a hint for the user to do this
should
be given at a reasonable place.
Well, to be honest, this is always the last place where I look for help.
It takes too much energy to read the readme when you are not sure
whether you have found the program you were looking for.
Usually it goes like this:
1. google for the topic I am looking for ("linux medicine" or similar)
which eventually spits out your homepage
2. on your site I get the information that some meta packages (whatever
that is) are provided for me (perhaps that information about it being
already a part of distribution (...in my Synaptic) might come somewhere
here)
3. start Synaptic and search for debian-med, which spits out all the
med-* packages
4. read the information provided about the packages, med-common first,
because it is somewhat privileged being common, pick the ones I am
interested in (pharmacy for me, practice to tell my girlfriend, and
several others I like)
(here I think I should get the information that hitting apply right now
will not get me all the fun, the "suggest" stuff)
5. look for the installed program in menu, if not found, I try running
the name_of_the_package in terminal (which should tell me that I have
to look for other executable files, and perhaps which ones)
6. if problems arise try man name_of_the_package or name_of_the_package
--help
7. if problems persist, read the text on your site to the end and
finally give up
8. very scarcely I remember there is something like the docs for every
package...
that lot of software is a "suggest" only. I
Are you sure that it is really "a lot" of software that is only suggests?
Can you please specify the suggested packages that you would like to
see as
depends? My strategy was to use "Depends if possible". The "if
possible"
is necessary because some software that is interesting for Debian-Med is
in the non-free or contrib trees on the Debian mirrors and thus do not
belong to the official Debian. That means I can not put Depends from a
package outside Debian (non-free) in a package inside Debian. This would
immediately exclude the meta package from main Debian. So if you find
a package that is in Debian main and should have a Depends but no
Suggests
I would be happy to change this. You can easily find this out by using
apt-cache show PACKAGE | grep ^Section | uniq
For instance
$ apt-cache show clustalw | grep ^Section | uniq
Section: non-free/science
shows that clustalw is non-free and thus only listed as Suggests in
med-bio.
Well, this sounds a bit complicated to me. Anyway it is fine with those
packages being a suggests as long as I know what to do with it. (that
marking for install and hitting apply will get only some)
And yes, it is a lot (in my case), med-pharmacy suggests chemtool,
med-practice suggests gnumed-client, med-physics suggests a lot,
recommends paw, med-cms suggests zope-zms. All depend only on
med-common. So when I hit apply button in did not install anything at
all... (I mean from the software I was looking for)
think that this information should be available before one installs a
med-* package (ie. on a description of a package) so even a beginner
will know, that this does not install all available software.
You are right here that the fact I explained above should be mentioned
in the description.
For little advanced users (who read man pages, but are not advanced
enough to know the location of doc files by heart) there might be
some information about it being only a metapackage and a link to the
readme file. And when the package is executed (like med-common in
xterm) it should write in the end something like:
/Note: This file is not intended to be executed in itself, please
refer to the manual pages (man med-common)./
You are right. Once I considered it to be a good idea to provide an
executable
in every meta package that just prints something like apt-cache show
would
print as information. But either it is a bad idea at all to use an
executable
(what do you think) or it should definitely a little bit more verbose
to be
useful.
I think it is very good idea. When I install some package I usually try
its name in xterm first. It should print the note and some information
about that suggest business in case the user missed that when installing
the package. Now I know that the information is there, but I missed it,
perhaps the note might say:
Note: This file is not intended to be executed in itself, for actual
executables see the "Suggests" and "Recommends" sections. For further
information please refer to the manual pages (man name_of_the_package).
As to verbosity, it prints a lot of "unnecessary" things. It does not
tell an inexperienced user anything and an experienced user would rather
use that apt-cache thing. I would say that maintainer and version
sections are ok, suggests, recommends and depends are together with that
note most helpful. (it tells me what I am looking for). That description
ok, why not if I am uncertain, I will run man name_of_the_package and it
will provide me with the description. In the man pages might be that
hint about /usr/share... directory. (as further reading)
As to what might be in the package description (that text which
appears in synaptic describing the package) I would suggest this:
for med-common:
/*Debian-Med Project common package
*This package provides the basic infrastructure of all med-* packages
and is needed by them.
Other packages in Debian-Med Project are:
** med-bio for biological research
** med-cms for publicating a ... on the internet
** med-dent for dental medicine
** med-imaging for image processing
** med-pharmacy for pharmaceutical research
** med-physics for radiation oncology, diagnostics imaging
and related fields
** med-practice for general practitioners
** med-tools for ...
** med-doc documentation, talk and ... (see "installed files")
Note: All these packages are so called metapackages. This means they
are not executable programs, but only links to other packages. This
way you will conveniently get all the non-commercial medical software
which is available for linux./
This is a very helpful hint. I think I will apply this quite soon -
just waiting
until the current unstable packages will hit testing. One more hint
because
I'm not sure you are comfortable with reportbug: It is perfectly all
right
and really apreciated if you post this kind of hints to the Debian-Med
mailing list. Another way to raise your voice would be to use the bug
reporting
tool reportbug and file this as bug report with severity "wishlist"
against
the debian-med package. The difference between a post to the list and
using the bug tracking system is that people who are looking at
http://bugs.debian.org/debian-med
will be informed about known (and solved issues) even if they do not read
this mailing list. But if you are feeling uncomfortable with reportbug -
just continue to use this mailing list as you did.
Well, I guess one step at a time is good enough pace for me... :)
Perhaps sometime later when I become more familiar with mailing lists. I
am glad that I already helped somehow.
For each med-* the description is simple and good, but might contain
again something like:
/Note: Some dependencies are suggestions/recommendations only. If you
plan to install those as well, please mark those for install separately.
What do you think about:
/Note: Please note that this package can not Depend from non-free
packages but the interesting packages from non-free are at least
Suggested for your information./
(Regarding the Recommends: Can you tell me the packages that you would
like to raise from Recommends to Depends?)
Ok, why not. It tells me the fact that I want to look for Suggested. It
seems that I have to install the Suggested packages one-by-one, do you
think that I might be somehow batched?
To your question... I have no idea. Sorry for that. What is the
difference between Recommend and Suggest by the way?
This metapackage depends on these programs:
...
...
And suggests these:
...
...
/
This is an interesting idea and I will think about it. The problem is
that the building process of the meta packages is a highly dynamic
process
and the control file of a meta package is assembled in the package
building
process by the cdd-dev tools from some task files. There would be a good
chance to extend cdd-dev to also add the Dependencies to the description
but I'm not completely convinced that this is a really good idea. The
reason is that in the long run we will have translations of the package
descriptions for several languages. If the content of the package
description changes frequently many translators will be kept busy
(because
they get a notification that something changed) but they will not
really have to do something (just a package name was added). If we
would decide not only to add the package name but even the short
description of the dependant package, which would be completely
reasonable,
the poor translators would have a really hard job. It is a known fact
that translators have problems when trying to translate this very
specific medicin/biology related terms. It becomes even worse if
different translators are working on the description of the real
package description of the dependant package and on the short description
inside the meta package.
So in short: I consider it not as the best idea to add the Dependencies
to the description but I would see what I can do to enhance the med-*
scripts to be more verbose about the Dependencies for instance by parsing
the dependency list and add the short decriptions of the package (which
should work also with translations because (once it is established) the
translated packages file would be used. Than we could add a hint into
the description of the package that explicitely advises the user to
call the script and read the information. We could even add a sign
whether some suggested or recommended package is really installed or
not. We could even add a options
med-* --install-suggests --install-recommends
to fix the suggestions easily if you think this would be the kind
of support users would like.
What do you think about this?
OK, I see your point. I do not think that this is needed in the package
information. If alerted, the user can right-click and see what the
suggestions and recommendations are. And I see that you have already
answered my question from before. Yes I would like to have such options
(if that is possible). It might be helpful if the note in package
information were something like:
Note: Please note that this package can not Depend from non-free
packages but the interesting packages from non-free are at least
Suggested for your information. If you would like them installed, run
name_of_the_package --install-suggests in terminal to install them.
I hope this helps to see problems of normal user like myself. And
thank you for reading all this stuff.
I liked your input very much and hope for further comments from you and
others to this topic.
Peter
Reply to: