ALSA and OSS

[Robert Millan]

On Thu, Sep 08, 2005 at 06:53:52AM +0200, Aurelien Jarno wrote:
> >As you might know, packages that assume ALSA is provided are one of the 
> >most
> >common reasons for a package to FTBFS on GNU/kFreeBSD.
> 
> True, that's one of the reasons of a package to FTBFS that is on the 
> not-yet-build list, though this is not the most common reason 
> (libtool/config.{guess,sub}).

Didn't know this.  That makes it FTBFS reason number one if we don't count the
problem that (usualy) are fixed automaticaly with no action from our part.

Let me guess.. selinux is next?  :)

> Well if it doesn't work well, this solution only hides the FTBFS 
> problem, and does not provide a solution. If we want the package to be 
> built but not work, it could be faster to provide empty .deb files...

True.  As you put it, doesn't sound like the benefit of having a lousy library
instead of a dummy one is worth the extra work required to put libsalsa in
shape.

> >Another option could be a d-d-a mail explaining the situation, or asking 
> >the
> >release team for how long we're going to support Linux 2.4 in Debian.
> 
> That doesn't work. I have already done that for selinux, and it doesn't 
> work. I even have the feeling that it increased the packages with 
> selinux enabled, as I said it is a target for etch to enable selinux.

ROFL.  We're in disgrace.. ;)

Perhaps it's a matter of the content.  What if we outline these points (I
think these are the most common matters of confusion):

  - OSS is NOT deprecated by the free software community, only by the Linux
  developers.

  - OSS is the only portable interface to access the sound system in more than
  12 different Un*x kernels (except sound daemons of course, but these only
  rely on either OSS or ALSA themselves).

  - The OSS implementations in free kernels like Linux or kFreeBSD are free
  software (GPL and/or BSDl).  If you run a propietary system, you get to run
  the non-free OSS only.

Another option is fixing lintian to detect when Arch: any packages depend on
Arch-specific ones like libasound2.  With some luck, we could even convince the
FTP assistants to disallow these in queue/NEW.  See "Fun with the NEW queue" by
Joerg Jaspert in:

  http://lists.debian.org/debian-devel-announce/2005/08/msg00011.html

(of course, libasound not being Arch: any is a pre-requisite for that.  I'm
sending a bug report)

> I already thought of something like that, but as I found the 
> "libasound2-dev [!kfreebsd-i386]" build-dependency ugly, I decided to 
> wait for the new dpkg. As it doesn't come, maybe we could just go with 
> "[!kfreebsd-i386]" ?

I think the new dpkg can be stalled for ages, and "!kfreebsd-i386" can be fixed
later when there is a need.  Makes no sense to wait IMHO.

-- 
Robert Millan