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

Re: LCC and blobs



[Please keep either debian-legal or myself in the CC list; I'm not
subscribed to debian-devel.]

Anthony DeRobertis wrote:
> Brian Thomas Sniffen wrote:
>>> So would a web-based firmware loader, that never saved the firmware to
>>> disk allow the drivers to be in main?
>>
>> Of course not.  It's fetching software, then using that software.  ICQ
>> software merely mentions messages, but doesn't use them.
> 
> ICQ uses the messages as instructions telling it what glyphs to display
> on your screen. That part of the message, though, might be free.
> 
> It does use significant features from non-packaged software --- message
> routing, buddy list management, buddy tracking, file transfer, etc.
> 
> We've elected to ignore ICQ's dependency on an ICQ server. We've elected
> to ignore a driver's dependency on firmware burnt in ROM or stored in
> flash --- even when it executes that code on the main CPU. We've elected
> not to ignore firmware that resides in RAM instead.
> 
> I'm not sure how to make a consistent (and still useful) position out of
> all that.

As I mentioned elsewhere in this thread, we have already solved this
problem, in the form of the definition of the "main" section.  We just
need to extend this to the case where the software can't be packaged at all.

If the non-free item in question was packaged in non-free, would the
package in main express a Depends:, Recommends:, or Build-Depends: on
it?  If so, the package in main belongs in contrib.

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.

We all understand what Depends:, Recommends:, and Build-Depends mean; we
don't need to come up with an alternate definition when we have a
perfectly good one already available.

Finally, we need to use some common sense to see when people are
suggesting things like "installer" packages for non-free software, as a
way to work around such dependencies.  Otherwise, someone could claim
that any package in contrib could be in main, because it only depends on
apt, not the non-free software it fetches and uses. :)

- Josh Triplett

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: