[PlanetCCRMA] dependancies

[Julius Smith]

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 
chip.
(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.
Thanks,
Julius

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
>libasound.so.1
>libasound.so.2
>libasound.so.2(ALSA_0.9)
>libasound.so.2(ALSA_0.9.0)
>libasound.so.2(ALSA_0.9.0rc4)
>libasound.so.2(ALSA_0.9.0rc8)
>libasound.so.2(ALSA_0.9.3)
>libasound.so.2(ALSA_0.9.5)
>libasound.so.2(ALSA_0.9.6)
>libasound.so.2(ALSA_0.9.7)
>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
>requirements.
>
>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
>happy).
>
>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)
>
>%description
>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...
>
>%files
>%defattr(-,root,root,-)
>
>%changelog
>* Sun Oct  5 2003 Fernando Lopez-Lezcano <nando@ccrma.stanford.edu>
>0.0-1
>- Initial build.
>==== CUT HERE ====
>
>
>_______________________________________________
>PlanetCCRMA mailing list
>PlanetCCRMA@ccrma.stanford.edu
>http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma

_____________________________
Julius O. Smith III <jos@ccrma.stanford.edu>
Assoc. Prof. of Music and (by courtesy) Electrical Engineering
CCRMA, Stanford University
http://www-ccrma.stanford.edu/~jos/