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

Re: can a kernel in main depend on firmware in non-free to work?

Le jeudi 30 octobre 2008 à 17:37 -0200, Alexandre Oliva a écrit :
> It does make a difference when the components don't quite form an
> inseparable unit, but rather they're just put together in a single
> tarball for convenience.

Kernel modules are not really separable from the kernel image. You can
split the files in different packages, but in functional terms they
would have to be always installed together. (This is because of serious
issues in the Linux kernel, but it is quite unrelated to this

> The fact that Debian does hard work to split Free from non-Free to
> keep portions of a package in main while moving others to non-free
> shows that this upstream package boundary is quite a thin argument for
> you to stand on.

> > The only thing that matters is package dependencies.
> But not as in '.deb requirements tags', but rather in 'compilation or
> execution requirements', as per the Debian policies, right?  And then,
> ultimately, it's Debian that decides what a Debian package amounts to.

Precisely. And because it’s pointless to split kernel modules from the
kernel image, there is all reason to put them in the same binary

> >> There *is* reason to split the linux package, I thought that was
> >> beyond any doubt by now.  Debian isn't supposed to ship non-Free
> >> Software, and Linux does include non-Free firmwares.
> > And this has already been the case for long.
> I can't tell what point you're trying to make with this statement, or
> how it relates with the conversation underway.  Can you please
> elaborate, so that I don't misunderstand what you were trying to
> communicate?

Non-free components (mostly firmware) have been split off from the
upstream sources in a separate source package in non-free
(firmware-nonfree) since before the etch release.

> > No, there is no doubt about that either. There is absolutely no need to
> > split these modules.
> Err...  Are you just voicing your personal opinion, or is this
> authoritative information about a decision you're in charge of, or
> widely known among Debian developers?  I don't know your role in the
> Debian project, so please bear with my ignorance.

This is just common sense from the only developer who is still losing
his time discussing with you.

> But do policies make room for a single Debian package build to create
> a binary .deb that goes in main and another binary .deb that goes in
> contrib?

Yes, it’s possible. But there is no reason to do that in most cases, and
especially for the kernel where it would annoy our users without
bringing anything good for the free/non-free distinction.

> Please do share.  What is contrib for, in your understanding?  

Contrib is a place for packages that require non-free components to run.
It is not meant as a pretext for hair-splitting. The distinction between
main and contrib is often blurry (see e.g. game console emulators), and
in doubtful cases our choice is generally to put the package in main. 

> And
> pretty please copy me, as requested in the Mail-Followup-To header,
> I'm not on this list.

Please do not rely on non-standard headers that a only handful of
clients understand, and that violate the protocol by not using the X-

> BTW, is this an appropriate forum for seeking enlightenment and
> offering suggestions about Debian policies, and how they apply to the
> decision at hand?  If not, I'd be glad to abide by suggestions of more
> appropriate Debian mailing lists.

If you have useful general suggestions, this is the place. If you have
useful suggestions about kernel packaging, you should write to
debian-kernel. If you want to go on this discussion, I suggest you do it
on debian-curiosa.

: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Reply to: