[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]



El dg 09 de 01 del 2005 a les 10:39 -0600, en/na Peter Samuelson va
escriure:
> [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.
> 
The purpouse of a software not says if a software goes in main or
contrib.
>    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. 

If you to use xpdf, you must to give it a pdf file, if you want tu use a
driver you need to give it a firmware blob.

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

This is the same point. You are going to care very much abut *which*
firmware are you loading on your driver. 
> 
>    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.
Yes, but the difference is only the difficult could be create them. Then
if you have a more difficult working sofware, it must be in contrib?
> 
> Peter
-- 
Miguel Gea Milvaques <debian@miguelgea.com>
Blog: http://www.livejournal.com/users/xerakko/

Attachment: signature.asc
Description: =?ISO-8859-1?Q?Aix=F2?= =?ISO-8859-1?Q?_=E9s?= una part d'un missatge, signada digitalment


Reply to: