Re: New virtual package: festival-voice (bug#112565)! -> Debian module policies

[Martin Albert <MartinAlbert@gmx.net>]

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