[PlanetCCRMA] dependancies

Julius Smith jos@w3k.org
Mon Oct 27 09:39:05 2003

I have a dependency snafu that perhaps someone can enlighten me about.

(1) I have to run kernel#2.4.21 or later to get support for my networking 
(2) I cannot install Planet CCRMA stuff because I don't have kernel#2.4.20.
(3) 'apt-get -f install' cannot fix the dependencies because kernel#2.4.20 
will not install, because kernel#2.4.21 is recognized as being newer and 
already installed.

Does anyone know of a clean way out of this mess?

I do not understand why kernel dependencies fail when the installed kernel 
version is obviously later than the required version.

Any advice appreciated.

At 05:51 PM 10/5/2003 -0700, Fernando Pablo Lopez-Lezcano wrote:
> > Hi all, I recently decided to break the habit of compiling my own music
> > software and use Planet CCRMA instead. I always like to compile my own
> > kernel and it is this that is confusing me right now. If I want to
> > install the Planet packages such as jack/ALSA etc, they complain about
> > needing a certain kernel. What is the best solution here? Can I get away
> > with just using the source kernel from Planet or must I install the
> > kernel that is metioned in the dependancy warning. If I do have to
> > install this kernel, I'll never actually use it which seems a bit of a
> > waste of time/disk space to me.
>There are several ways of dealing with the problem. First of all, the
>rpm dependencies have to be met or you won't be able to use apt to
>managed the installed packages (the whole point of Planet CCRMA is ease
>of installation, including alsa and the kernel). This is why you need a
>certain kernel when you try to install a Planet CCRMA package:
>   most Planet CCRMA alsa related packages need:
>     alsa-lib-xxx --> which depends on
>     alsa-driver-xxx --> which depends on
>     alsa-kernel-KERNEL_VERSION-xxx --> which needs
>     kernel-KERNEL_VERSION
>You can satisfy the dependencies at several levels, depending on what it
>is you are installing yourself and how.
>The best option would be for you to build proper kernel and/or alsa
>packages with the options you want.
>The next best would be to build alsa rpms that match the kernel you
>installed (but you would have to tweak the spec file of the alsa-driver
>packages to _not_ require all the kernel dependencies - they are not
>there because the kernel you installed is probably not an rpm package).
>The next level down would be to _really_ cheat and make the system
>believe you have alsa installed through an rpm (which you probably do,
>but not in a way that the rpm database can see)...
>For example:
>- you install the kernel and alsa subsystem (this assumes you don't use
>   rpm packages for the kernel and alsa):
>   Somehow you have to provide the alsa-lib requirements so that you can
>   install Planet CCRMA packages that depend on alsa-lib. So what is it
>   that is provided by alsa-lib?
> > rpm -q --provides alsa-lib
>alsa-lib = 0.9.7-1.cvs.rh90
>You can see what needs those "provides" by doing:
># rpm -q --whatrequires libasound.so.2\(ALSA_0.9\)|wc
>      38      38     799
># rpm -q --whatrequires libasound.so.2|wc
>      46      46     987
>And the rest get 0 hits.
>So, to keep the packages happy you would have to create an alsa-lib
>package (or whatever name you prefer) that "provides" those
>This is obviously cheating :-) because the package does not reflect what
>you have installed (you installed stuff with the normal configure; make;
>make install commands, not with a properly built rpm). As long as you
>_really_ have everything installed then things will work.
>I'm appending a sinple spec file you could use to generate a fake
>alsa-lib-dummy package that meets the current dependencies of the alsa
>related Planet CCRMA packages... (I tested it in the sense that I could
>erase all the alsa-* packages and still get "apt-get check" to be
>Again, this is "cheating"... you _have_ to have a properly installed
>kernel and alsa subsystem (alsa-driver, alsa-lib, alsa-utils and
>alsa-tools) for all this to really work.
>-- Fernando
>==== CUT HERE ====
>Summary: Dummy alsa library package
>Name: alsa-lib-dummy
>Version: 0.0
>Release: 1
>License: None
>Group: System Environment/Libraries
># cheat the dependency system
>Provides: libasound.so.2 libasound.so.2(ALSA_0.9)
>Empty package that provides the correct dependencies for all
>ALSA related Planet CCRMA packages. This is a gross hack. All bets
>are off. You are on your own...
>* Sun Oct  5 2003 Fernando Lopez-Lezcano <nando@ccrma.stanford.edu>
>- Initial build.
>==== CUT HERE ====
>PlanetCCRMA mailing list

Julius O. Smith III <jos@ccrma.stanford.edu>
Assoc. Prof. of Music and (by courtesy) Electrical Engineering
CCRMA, Stanford University