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 discussion.) > 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 package. > >> 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- prefix. > 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. Cheers, -- .''`. : :' : 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?=