[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LCC and blobs

Marco d'Itri wrote:
> On Jan 07, Josh Triplett <josh.trip@verizon.net> 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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: