On Tue, Jan 02, 2007 at 02:24:13PM +1100, Robert Collins wrote: > > Because the vast bulk of users do *not* roll their own kernels [yes, an > assumption, but I'm pretty confident here :)]. > I disagree. I think that while it is not the majority, a sizeable portion of the user base installs a home-rolled kernel. > Not having any dependency meta-data down to the kernel layer *when there > is an actual dependency* makes life harder for the majority of users, > and I think its acceptable for you to have a minor inconvenience when > you want to install an unpackaged kernel *and* remove all packaged > kernels that would meet the dependencies in order to make life much > easier for all those users that do not roll their own kernel. > So what you are saying is that you want me to be confused. Let's say I have at some point installed a kernel that meets the dependency for your package, though I have never heard of your package. At some later time, I roll my own kernel and use it, however it is not good enough to meet the dependency for your package. Perhaps, I left out some important module or something. Now, I find out about your package and install it. Every indication from aptitude is that everything installs OK. Now, I try and use your package and it *doesn't* work because I am not running the kernel it depends on. What would I do at that point? Personally, without any further documentation or information available, I'd file a bug. If I used reportbug, it would also indicate that I had the "correct" kernel installed, but not running and you would end up with a bug report along the lines of "it doesn't work". Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com
Attachment:
signature.asc
Description: Digital signature