[PlanetCCRMA] Forcing dependencies with non-RPMed ALSA install

[Harri Haataja]

On Wed, Dec 04, 2002 at 12:01:02AM +0000, Stu Yarrow wrote:
> I've been installing PlanetCCRMA, and I ended up rebuilding the kernel
> and baking my own ALSA install from tarballs so I could get my onboard
> sound (snd-via82xx) working.  It all works fine, but when I come to
> start installing the application RPMs everything, unsurprisingly,
> requires the ALSA RPMs.  Is there any way I can trick apt into
> thinking I already have the ALSA packages installed? Or any way to
> install them without disturbing my current ALSA setup?

You can make your own rpm packages that have just a bit higher version
number (or epoch) than the ones in apt database and make them provide
the dependencies you want and contain maybe just a README or something.
This is quite common when package names change and you can't go and fix
it (Cobalt, JDK, ODBC...).

A better option would be to go and fix it. IE only install stuff as rpm.
If you want something that's not already in some rpm, you make an rpm
that contains it. Sometimes it's a matter of just recompiling the
src.rpm (do add a bit to the revision number or you'll end up with two
identically named packages with different version numbers).

I hope that wasn't to confusing. I'll try a specific explanation:

It sounds like the problem is you building alsa unmanaged.

Solution #1:
Build ALSA managed. get a src.rpm (or make one), do the neccessary
changes, rebuild install. 

Solution #2:
Lie to the package database. Make a package with no files in that claims
to provide alsa-foo (whatever the packages depend on) and install that.
Naturally, you must take care that you provide what the package claims
to or stuff may not work. 

Dependencies are there to help you keep track of what has to be
installed in order for another bit to work. Package managers match and
help enforce them. Ofcourse that needs someone to make sure there's
packages that provide the adequate capabilities.

-- 
ASR: We took both pills.