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

Re: LCC and blobs

Marco d'Itri wrote:
> On Jan 06, Josh Triplett <josh.trip@verizon.net> wrote:
>>An ICQ client wouldn't Depends: icq-server; it might Suggests:
>>icq-server, but that's OK.  A driver might at most Suggests:
>>burned-in-firmware-for-reflashing, but it would Depends: or at a minimum
>>Recommends: firmware-loaded-by-driver.
> I can't see how you did come to these conclusions.

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.

If the firmware we have packaged in non-free comes standard on the
device, then the driver does not need a copy of the firmware, so it does
not have a dependency on it.  It is also possible that the driver might
Suggests: the firmware, for use in the situation you have previously
suggested in which the user might want an alternate firmware.  However,
the driver package certainly doesn't need the user to install the
firmware in order to run.

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
should Depends: the firmware.  I also included the possibility of
Recommends:, for the situation you have previously proposed in which the
user doesn't want the version Debian packages; I would tend to argue,
however, that there is no difference between that and wanting another
version of any other packaged software in Debian.  In any case, I think
that the loosest dependency that makes sense is the definition of
Recommends from Policy 7.2: "The `Recommends' field should list packages
that would be found together with this one in all but unusual

>>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.

Otherwise, we end up in the absurd situation in which if the non-free
item becomes distributable (slightly less non-free) and someone packages
it in non-free, such that the driver can then properly express its
dependencies, the driver suddenly needs to go to contrib.

- Josh Triplett

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: