

Dependency on oss-compat for (old) apps using /dev/dsp?

Is it a RC bug if a package using /dev/dsp on GNU/Linux does not
explicitly depend on oss-compat?  I remember a recent release goal
proposal about dropping/fixing apps that still do that, but I can't
find it at the official release-goals list (anyway, even if it was
approved, release goal related bugs are not RC AFAIK).

Some more details:

Cytnhiune (cynthiune.app, a music player for GNUstep) has 3 "output"

  * OSS (deprecated in the Linux kernel long time ago)
  * Esound (already deprecated in GNOME, to be removed from Debian
    in the foreseeable future)
  * aRts (already deprecated in KDE, to be removed from Debian even
    sooner, I guess)
In view of the release goal proposal, I guess I'll have to write an
ALSA output bundle soon.  My question is what is the right thing to do
until then.

I tried to figure out why /dev/dsp exists on literally all my
workstations, and hence cynthiune.app worked out of the box without me
doing anything special.

On one machine, it was pulled in as a dependency of libarts1c2a, which
itself got installed as a dependency of libarts1-dev.  On another one
it was installed because bb (not very popular package) depended on it.
On all the others, it was installed since libdv4 (dependency of
gstreamer0.10-plugins-good) recommended it.  So I purged oss-compat
and all dependent packages and... discovered that cynthiune.app no
longer plays, and even worse, there's no error message telling the
user what's going on.  Since none of these packages (oss-compat's
reverse deps) should be present on a pure GNUstep workstation, my
conclusion was that cynthiune.app working for me is mere coincidence.

So, should I add oss-compat as a hard dependency ASAP until I manage
to come up with an ALSA bundle (to be the default for all linux

Reply to: