[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. Peter
Attachment:
signature.asc
Description: Digital signature