Re: non-free but distributable packages and kernel firmware
On Wed, Apr 06, 2005 at 12:44:36PM +0100, Mark Brown wrote:
> On Wed, Apr 06, 2005 at 09:08:21AM +0200, Sven Luther wrote:
>
> > As thus i was wondering if, together with the volatile effort, it would not be
> > time for us to split the non-free archive into two parts, namely :
>
> > 1) non-free-but-freely-distributable
>
> > 2) rest of non-free
>
> While that does look like a useful distinction, especially for (as you
> say) people building CDs and the like, there also seems to be a
> reasonable community of people who are willing to accept non-free
> downloads to hardware but still don't want non-free software running on
> the host system. That would suggest that it would also be worth having
> a separate section specifically for data to be downloaded to hardware,
> or perhaps for non-free data in general since there seems to be some
> crossover with people who wouldn't mind things like non-free standards
> documents either.
Well, there you enter in the discussion of additional classification of
non-free, which has been rejected upto now as too much trouble.
My image of this would be for the debian-installer to recognize that a given
piece of hardware needs a driver module that is in
non-free-but-freely-distributable, and informs the user about this fact, and
asks him (if network is up) if he wants to download it, or otherwise provide
the driver .udebs through floppy, usb key, cdrom or whatever.
This behavior could be trigered by a debconf variable, which could suitably be
pre-seeded to produce the non-free-but-distributable and the free version of
it. The free just informing the user that the hardware is not supported with
free drivers, and not proposing the download.
All other kind of classification would probably be something usefull, but
nobody seems to be willing to invest the time to do it, so ...
Ideally the non-free packages file would have in the package description a
field listing the reasons for it being non-free (no-source,
restricted-distribution, firmware, whatever), and maybe an extended
description field if needed, and apt could be modified to match on those
keywords.
Friendly,
Sven Luther
Reply to: