Re: New virtual package: festival-voice (bug#112565)! -> Debian module policies
- To: debian-devel@lists.debian.org
- Subject: Re: New virtual package: festival-voice (bug#112565)! -> Debian module policies
- From: Martin Albert <MartinAlbert@gmx.net>
- Date: Thu, 1 May 2003 20:23:06 +0200
- Message-id: <[🔎] 200305012022.54049.tim@eisbox.eis>
- In-reply-to: <pan.2003.04.30.08.57.51.834243@smurf.noris.de>
- References: <pan.2003.04.17.15.15.44.832302@smurf.noris.de> <Pine.LNX.4.10.10304181413140.31603-100000@magnetron.ieee.uow.edu.au> <pan.2003.04.30.08.57.51.834243@smurf.noris.de>
On Wednesday 30 April 2003 10:57, Matthias Urlichs wrote:
> > If multiple packages containing the data can be installed, though,
> > you will of course need to use the alternatives system to manage
> > which one gets used.
>
> That is controlled via festival directly. Using alternatives is
> probably not right in this case; there's a system-wide default file
> where root can enter the default. You don't use alternatives for the
> system-wide default choice of 75- vs. 100-dpi fonts either; the same
> applies here, IMHO. --
Welcome to the Dark Zone.
A virtual package alone doesn't gain you anything here and is plain
wrong IMHO.
I've tried several times already to get communications going:
Debian lintian does the Right Thing, knows about dynamically loaded
'modules'. It hit xlibs (xlibs-pic), ...
But a policy is missing on the 'application level': at package install
time, presentation of the distribution, responsibility of a sysadmin in
charge against 'Joe User'.
Current practice: users use apt, ignoring 'Suggests' and 'Enhances'.
Packages with correct dependencies apparently fail for 'Joe User' ->
BTS -> Packages start to *Depend on foreign application modules*, eg.
Depends: festival-voice, or Depends: libggi-target.
- This is wrong. The application depends on festival, not installed data
files, likewise no app depends on ggi display targets, the only correct
dependancy is libggi. (The only valid case were eg. a script_fu working
with a certain gimp module, or the 'dominant-fractals' package that
needs festival-harsh-female-voice installed.)
- This is pointless, as the dependency on that virtual package is
resolved randomly (for this discussion). Users live with that unknown
choice or admin installs, removes and configures anyway.
It is up to the package (festival, libggi, ) to be in a usable and
satisfying state / config. It is up to the admin to install what his
users might need. It is that 'Joe' who misses on that, complains, ...
In theory Debian allows eg. maintainer scripts at debconf time to ask
for modules to install and apt install them, also a nice extra
configuration program could do that. This fails the easy way for dialup
users.
(At least to me, please correct me) is the currently accepted practice
for 'Task packages' rather unclear. There is a rather 'closed' task
selector and some desperate task packages.
Correct, but impractical, were (lots of) meta packages like
festival-male-spanish or ggi-console, ggi-devel4all-libs, ... The
package cache has limits, however.
In essence, the problem becomes 'solved' as above or is ignored. In fact
is this the most commonly accepted correct way to deal with it. The
admin is the one responsible to use the package tools and lists
together with installation insctructions and other
/usr/share/doc/packagename/*.
But there are the USERS, apt-get installing hatman, that depends on
libggi, all is fine, just no visible output, no display-target
installed. A perfectly valid choice; which other one had to be pre
setup by the package maintainer: an x target pulling libs the user
didn't want, or the console targets he doesn't see on his remote X
terminal? Which (not so small) festival voice package should have been
installed, *without even knowing the language* of the target
installation?
I have (a new upstream source and) a recent bug open, that requests for
a new, more specialized virtual package, libggi-target-hires, so that
it will be less tedious to do it the wrong way. I guess i won't do it
(but was tempted already to give in ;).
So, i'm not only currently very open for any suggestions, ideas, input.
Willing to collect and discuss and take further initiative - but i think
about it on my own for such a long time yet, that i'm going in circles.
Have a nice Debian - greetings, martin
Reply to: