On Tue, Jan 02, 2007 at 02:05:01PM +1100, Robert Collins wrote: > > I think you are arguing around the issue. An example may help. Consider > an application that needs 'libhello' built with ssl support. i.e. > Depends: libhello-ssl0 > > That installs /usr/lib/libhello.so > > Now, if I fiddle with the system: change the runtime library path, > dpkg-divert /usr/lib/libhello.so, or do other tricks, the application > will stop working. > Right. But you do those things (which are by no means common occurrences among a significant portion of the Debian user base) yourself understanding that they may cause problems if you don't know what you are doing. > The point of packaging is to let things work as well as possible by > default. Its not true to say that kernels and libraries are identical in > their constraints : and I haven't claimed that. What I have claimed is > that in no case is there any guarantee that what dpkg *thinks* is > present actually is. > Then why bother with dependencies at all? Because in the vast majority of the cases, what dpkg things is present actually is. However, it is extremely common for people to compile their own kernels and install them *without* using Debian packaging. The same cannot be said of most common libraries. > But where we can signal to it that something is *not* present, that is > useful, as dpkg can then signal to the user that intervention is > required. > Right. But depending on a particular kernel image is an artificial limitation. If I roll my own kernel without using Debian tools (which is a fairly common practice), why should I have to work around your package's dependencies to get it installed? Simply document what is necessary in the way of kernel support and let me sort it out. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com
Attachment:
signature.asc
Description: Digital signature