Hi, I am still favouring the solution using "Depends" and scripts to detect whether you are running the right kernel.
First, I think "Depends" is what should be done because that's what package management systems are about in the first place: declaring what you need to have to be able to run something. If you decide to install stuff outside your package management system, it is your problem if it later complains about missing dependencies. That's the price you have to pay. And I don't think anybody who is running a self-compiled version of libc is expecting package maintainers to downgrade their dependency to "Recommends" or remove it completely. Second, what about users still running with 2.4 kernels? Without a dependency they will get an automatic update that leaves them with a broken package. I don't think they would welcome that. And I don't think it is right to punish regular users that have clean setups because others don't want to clean up theirs (besides, I happen to build my kernels using kernel-package, and I like it a lot because it is convenient and it does exactly what I want it to: allow me to custom-build a kernel and yet have the result easily integrated into the regular package management). So from my point of view there still is no valid alternative to declaring a "Depends" on kernel-image-2.6 and having run-time checks for the right kernel version (whereever possible). People running 2.6 without having it registerd with dpkg can always tell dpkg to ignore the dependency. And finally, to come back to my initial question: Is there a way of declaring a dependency on NPTL other than depending on kernel-image-2.6? Best wishes, Martin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
