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

Re: Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]

[Miguel Gea Milvaques]
> I don't undestand why software loading files (as we are talking) must
> be in contrib. An example: xpdf, if you have not a pdf file you could
> not use it, only it gave us a blank page. You could read a lot of
> different files, a free pdf files or a non-free pdf files, and xpdf
> we never thing to put xpdf in contrib.

There are several reasons why content viewers are not analogous to
device drivers.  Well, at least three reasons:

1. Most importantly, it's a difference of *purpose*.  The purpose of
   xpdf is to view arbitrary PDF files.  The purpose is not to load up
   a PDF file and then do something completely unrelated, like play
   tetris.  If for some reason a tetris game required a PDF file to be
   on hand in order to let the user actually play tetris, it certainly
   should ship a working PDF file, or depend on something that does.

   It would be hard to argue that the purpose of a NIC driver is to
   load a firmware blob.  Loading the firmware blob is part of the
   necessary procedure, but it is incidental; the user does not care
   about that part.  It's not as though most users would install the
   NIC driver just to see their favorite firmware file load and result
   in some sort of status printk.

2. The PDF file is full of information which is to be displayed to the
   user, and most PDF files have unique information in them.  The point
   of xpdf is to convert this information to a human-readable
   representation.  Thus, users care very much about *which* PDF file
   they are loading into xpdf - it's not like they just need any
   arbitrary PDF file.  Put a different way, there's no way to predict
   that most users would be satisfied by specific PDF content that
   Debian might then ship as a convenience.  Most users would not.
   They don't want content selected by Debian, they want whatever
   content they might run across.

   The firmware used by a NIC driver, on the other hand, has no
   user-visible content; certainly it has no content that the user
   specifically cares about.  In the common case, there is nothing to
   distinguish between one firmware release and the next, other than
   bugs fixed according to the release notes.  In the less common case,
   some versions of the firmware will add usable features to the
   driver, like hardware checksumming of TCP packets.  Even then,
   although the user may say "I want version X of this firmware because
   I heard it makes the driver faster", there's still a limited and
   predictable range of firmware content people might ever want.  To
   the extent that this ceases to be true (as, for example, with
   Linux-based wireless access point hardware, where a community
   develops around producing non-vendor firmware that does cool new
   things), it begins to make sense to treat those cases as data
   loaders which needn't provide or depend on specific data files.

3. There's a very real expectation, in the PDF case, that the user
   could create his or her *own* PDF files, using any number of tools
   in Debian or not in Debian.  The user could quite reasonably wish to
   install xpdf *solely* to view locally created content.  If you find
   that hard to believe, think about how most people use xdvi.

   Firmware files are not the sort of thing people can create their own
   versions of.  In most cases the format is not documented and there
   are no free or even publicly available tools for this, and even in
   cases where it *is* documented, this is not by any stretch of the
   imagination a typical use case.


Attachment: signature.asc
Description: Digital signature

Reply to: