Marco d'Itri wrote: > On Jan 07, Josh Triplett <[EMAIL PROTECTED]> wrote: >>I'll assume for the moment you are only disagreeing with the >>driver->firmware dependencies, not the client->server dependencies, >>since the latter is standard Debian policy. > > No. What I'm saying is that if you stretch the definition of > "requirement" enough to cover firmwares then it will cover also things > like ICQ clients.
I don't believe that follows. Consider the hypothetical existence of all four of the following packages: icq-client, Free Software in main icq-server, non-free but distributable in the non-free section driver, Free Software in main firmware, non-free but distributable in the non-free section I am making the purely technical argument that driver should Depends: firmware or at least Recommends: firmware, while icq-client should at most Suggests: icq-server. The latter is clearly established by existing Debian practice with packages of client and server software. For the former, in addition to basic definitions of dependencies (the driver requires the existence of a particular userspace file in /usr/lib/hotplug/firmware, provided by another package), there are concrete examples in Debian, such as at76c503a-source Depends: atmel-firmware . Would you argue that at76c503a-source should neither Depends: nor Recommends: atmel-firmware ? If so, why? If you changed it, how long do you think it would take for a user of that package to file the obvious RC bug saying "the driver won't work because it can't find the firmware, why didn't you put in a Depends?"? >>On the other hand, if the driver must load the firmware, then the driver >>cannot correctly function if the firmware is not present, so the driver > > No, I already explained why this is wrong. The driver functions > correctly and is fully functional with or without the firmware being > loaded in the device. The firmware being loaded or not in a device does > not change the essence of a driver nor its capabilities (actual or > potential). The wonderful thing about the dependency-based test I have suggested is that we can argue in very concrete technical terms. Specifically, your argument seems to suggest that if both the driver and the firmware are packaged, the driver should not Depends: firmware or even Recommends: firmware. See above for why I believe this is wrong, from a purely technical perspective: from the users point of view, the driver simply doesn't work, because it can't access a file that it requests from userspace, because the package providing that file isn't installed. >>>>We all understand what Depends:, Recommends:, and Build-Depends mean; we >>> >>>Not if they refer to things which are not debian packages. >> >>I'm saying that from the perspective of checking the dependencies of a >>package in main, we should treat anything that is "too non-free for >>non-free" as identical to things packaged in non-free. > > Yes, but if the firmware of a device is considered a dependency of a > device driver then an ICQ server has to be considered a dependency of an > ICQ client. Perhaps you could fill in the details of of the logic behind that huge leap? - Josh Triplett
signature.asc
Description: OpenPGP digital signature
