Re: can a kernel in main depend on firmware in non-free to work?
Hi, Peter, Thanks for your very informative response. You've confirmed my understanding that the main/contrib split is not about software freedom at all. I've thus come to the conclusion that it was motivated by the other Debian priority. Please bear with me while I explore the consequences of this conclusion and hopefully provide some food for thought. Which of these two you think is better for the user: - have software that won't work installed by default on their systems, without much opportunity for acting or even becoming acquantined with the suggested components, taking up disk space and bandwidth (e.g., a kernel containing modules that won't work, even if you install every package in main and contrib). Worse, software that might give the user the impression that something is going to work (module is loaded, reports some progress), but then fail pretty much silently, giving no information to the user as to what the problem is (namely, the lack of Free Software to perform the needed function, and the effective impossibility of developing such Free Software) - have software that will work to the fullest extent possible installed by default (a kernel package containing only modules that don't depend on any package outside main), and split into separate packages any components that couldn't possibly work out of the box, that will document, through dependencies, whatever else they require to function, even if sacrificing freedom, among packages provided out of Debian servers and mirrors ? I find it a bit disturbing that some (fortunately few) people who will promptly bring the priority for users into a debate to justify the packaging and distribution of non-Free Software will just as promptly forget this priority when it would amount to a minor burden for package maintainers. Admittedly, dealing with kernel modules as separate packages is far more involved than any other package split, which might require some long-term efforts to accomplish cleanly (or not, I'm not on par with how Debian deals with this). Meanwhile, I don't see any plausible reason to override the SC-stated priorities with some minor developers' convenience. There's a trivial solution for the mean time: have say two separate kernel builds, one for main, that wouldn't burden users with non-functional drivers, and one for contrib, that, when manually installed, would name the additional packages that might be necessary for portions of the package to work, at which point the user would be prompted to make informed decisions. > It is not artificial; our kernel package follows the same aggregation > as upstream (ftp.kernel.org). Not quite. Debian splits out kernel documentation, kernel headers and kernel image+modules into 3 separate packages, just to name the ones that jumped at me last time I looked into this. Splitting out some modules isn't quite as trivial, but it's not like it couldn't be done, when abiding by the two priorities stated in the SC depends on it. > the bundling is certainly more convenient ... for whom? Are both priorities being well-served by this bundling? Best, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist [EMAIL PROTECTED], gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can a kernel in main depend on firmware in non-free to work?
[Alexandre Oliva] > That's why packages that contain Free Software along with > documentation under licenses that don't pass the DFSG end up split > into separate packages. Keeping the documentation that didn't pass > the DFSG wasn't deemed acceptable, neither was moving the whole > package to non-free. The difference between main and contrib is not at all the same as the difference between main and non-free. > > Because the kernel is perfectly usable without the firmwares. > > But how about the specific modules that require them, the ones that > got this sub-thread started in the first place? It doesn't make > sense to me to frame the discussion in such terms as most of Linux is > useful without the component's dependencies, when what we're talking > about is the component, not the whole. This really is about our package dependency relationships. 1) The Social Contract says we will not make the system require the use of non-free components. We interpret this to mean 'main' (i.e., Debian GNU/Linux) needs to be a closure across Depends. 2) We recognize that a lot of free software does depend on non-free components - hence our 'contrib' section. However, we do _not_ say that contrib is not free software. So the reason we have contrib is _not_ so that Debian can be only free software, but so that Debian can be self-contained. 3) From a technical standpoint, if you have one big package that has lots of little executables or plugins or modules, some of which do not work unless a third-party component is present, obviously you can do it either of two ways: 3a) main package Suggests: plugin package plugin package Depends: third-party package 3b) full package Suggests: third-party package The effect on "user freedom" is exactly the same. We are shipping (in main) only software that meets our licensing requirements. Users have the same choice of whether to install the non-free software to obtain the corresponding functionality. The only real difference (again, from a technical standpoint) is whether there are 2 packages to keep track of, or 3. > > Does the kernel require the firmwares in non-free for execution? > > Portions of it do, for sure. Those portions are artificially > packaged together with the rest of Linux. If that's an argument to > put something in main rather than contrib, then there's no reason for > contrib to exist, since all of main+contrib amounts to a single > "package" called Debian. It is not artificial; our kernel package follows the same aggregation as upstream (ftp.kernel.org). It is true that we could decide to unbundle some or all modules, for various reasons. But the bundling is certainly more convenient, and (as I argue in points 3a / 3b above) I don't believe it has any real effect on user freedom. HOWEVER, if we had several packages originally separate, and decided to bundle them not for technical reasons, but so that a 'contrib' package could be pulled into 'main', I think that would be wrong. Because, as you say, that would be gaming the system, letting a technical decision be adversely affected by a desire to exploit a loophole in our interpretation of the Social Contract. We aren't, or shouldn't be, looking for loopholes. We are, or should be, making the best technical decisions we can, and then ensuring that those decisions are consistent with our foundation documents. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 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. signature.asc Description: Ceci est une partie de message numériquement signée
Re: can a kernel in main depend on firmware in non-free to work?
On Oct 30, 2008, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Whether they are plugins or modules or whatnot is irrelevant here. I'm not sure on what policies your statement is based on, but clearly to me what defines a package is not just an artifact of upstream packaging that Debian itself is Free to modify, and quite often does. 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. Say, Debian splits out the kernel documentation and kernel headers from the kernel image+modules, although they ship in a single package upstream. Say, the stuff David Woodhouse put together in the kernel firmware git repository hardly forms a unit or a package proper, it's just a bunch of unrelated firmware files. It doesn't make sense to push them all into main just because they're released in a single tarball. 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. >> 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? >> The doubt is whether the split is going to stop at the firmwares, or >> also cover the modules that require the firmwares. > 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. I can see that, given a certain set of policies, there would be no need for such a split. But, heck, it's not even clear to me whether the policies distinguish source and binary packages. Like, I know the sources for main binaries can't contain non-Free components, so different sources are used for main and non-free split builds, and that's how it should be IMHO. 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? If so, this would enable the trivial creation of separate packages for kernel modules, in contrib, that explicitly Depend on the corresponding non-Free firmwares in non-free, while the binary package in main is self-contained, fully-functional (i.e., no code is limited in its functionality because some other piece it requires is absent), easy to maintain (I suppose) and even amenable to run-time combination with the modules that have non-Free dependencies, for those who tolerate or even like that. >> it could be that I'm just still missing something. If so, please >> share your enlightenment. > It seems you are misunderstanding what contrib is for. /me missed the enlightenment sharing requested above :-( Please do share. What is contrib for, in your understanding? And pretty please copy me, as requested in the Mail-Followup-To header, I'm not on this list. 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. Thanks in advance, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist [EMAIL PROTECTED], gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can a kernel in main depend on firmware in non-free to work?
Le mercredi 29 octobre 2008 à 22:10 -0200, Alexandre Oliva a écrit : > > Because the kernel is perfectly usable without the firmwares. > > But how about the specific modules that require them, the ones that > got this sub-thread started in the first place? It doesn't make sense > to me to frame the discussion in such terms as most of Linux is useful > without the component's dependencies, when what we're talking about is > the component, not the whole. Whether they are plugins or modules or whatnot is irrelevant here. The only thing that matters is package dependencies. > 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. > The doubt is whether the split is going to stop at the firmwares, or > also cover the modules that require the firmwares. No, there is no doubt about that either. There is absolutely no need to split these modules. > > Does the kernel require the firmwares in non-free for execution? > > Portions of it do, for sure. We don’t talk about portions, but about packages. The kernel package does not require binary firmwares for execution. > Could it be that convenience and limited interpretations of practical > consequences of policies are turning against the actual policies and > priorities? It unfortunately looks like it from where I stand, but it > could be that I'm just still missing something. If so, please share > your enlightenment. It seems you are misunderstanding what contrib is for. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: can a kernel in main depend on firmware in non-free to work?
On 28 Oct, 2008, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le mardi 28 octobre 2008 à 14:12 -0200, Alexandre Oliva a écrit : >> I hope the prevalent interpretation of Debian's rules and policies >> isn't so lax as to make room for such manipulation as packaging stuff >> in main that belongs in contrib or non-free just because it happens to >> be part of the same upstream package. > It's not manipulation, it is the obvious result of how main and contrib > are split. > For another example, poppler needs a non-free package (poppler-data) to > read PDFs written in some languages. Should we move poppler to contrib > because of these languages? No, but it would make perfect sense to move to contrib the modules/components/plugins that requires poppler-data to display/read PDFs written in those languages. Even more so if they were packaged together just for e.g. convenience of download, and building them separately would be just as simple. Kernel modules *are* plugins, and the Linux build machinery is designed to enable just this kind of convenient separate building. I understand that, from a maintenance point of view, it's not so convenient to keep modules built separately, but hey, Debian's priorities are not to keep things easy to maintain, but rather freedom and users. (And there's often much discussion whenever the long-term conflicts with the short-term in either or both priorities.) That's why packages that contain Free Software along with documentation under licenses that don't pass the DFSG end up split into separate packages. Keeping the documentation that didn't pass the DFSG wasn't deemed acceptable, neither was moving the whole package to non-free. Thus the split, in spite of the inconvenience and maintenance burden. Now, why shouldn't the same care be applied to one of the most important packages in the distro? >> In fact, I have evidence to the contrary: a number of packages that >> ship as a unit upstream are split by Debian into separate packages > I don't know of such a package, but if there are, that's fine. Just > unnecessary. The alternatives, AFAIK, would be to move the entire package to non-free, no? (Assuming disrespecting the SC is not an option.) > Because the kernel is perfectly usable without the firmwares. But how about the specific modules that require them, the ones that got this sub-thread started in the first place? It doesn't make sense to me to frame the discussion in such terms as most of Linux is useful without the component's dependencies, when what we're talking about is the component, not the whole. Consider this scenario: Here's a package containing components A, B, C and D. Assume they're available separately and also as a single unit A+B+C+D upstream. A is a very important component, it's Free, and it doesn't depend on anything outside main, so it says in main. B is Free, not quite as essential, but it still doesn't depend on anything outside main. It could be packaged together, but it is made a separate binary package nevertheless, also in main. C is non-Free, so it's split out, and released in non-free, if at all. D requires C, but D itself is Free. It would make perfect sense to split D out into a package in contrib, that explicitly depended on C, so that people who found they needed D would know they needed C as well. This would also abide by the main/contrib split policies, but no, let's keep A+D in main as a unit, just because. Is there any justification other than 'because I say so'? > Since they only extend its functionality to support more hardware, > there's absolutely no reason to split the kernel packages. 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. The doubt is whether the split is going to stop at the firmwares, or also cover the modules that require the firmwares. > No, the main/contrib distinction comes precisely and uniquely from > dependencies (Depends/Recommends vs. Suggests). My reading of the policy is that this is an implementation detail of consequences of the policy, not the policy itself. > Does the kernel require the firmwares in non-free for execution? Portions of it do, for sure. Those portions are artificially packaged together with the rest of Linux. If that's an argument to put something in main rather than contrib, then there's no reason for contrib to exist, since all of main+contrib amounts to a single "package" called Debian. Sure, it's not a single .deb; one could take the exercise of putting stuff that belongs in contrib with stuff that belongs in main as far as needed to show the weakness of this interpretation, and your argument is living proof of that. So what is the point of the distinction, if it can be gamed so easily? Was is not to keep Free Software that depended on non-Free Software (thus useless for those who are ali
Re: can a kernel in main depend on firmware in non-free to work?
Le mardi 28 octobre 2008 à 14:12 -0200, Alexandre Oliva a écrit : > I hope the prevalent interpretation of Debian's rules and policies > isn't so lax as to make room for such manipulation as packaging stuff > in main that belongs in contrib or non-free just because it happens to > be part of the same upstream package. It’s not manipulation, it is the obvious result of how main and contrib are split. For another example, poppler needs a non-free package (poppler-data) to read PDFs written in some languages. Should we move poppler to contrib because of these languages? > In fact, I have evidence to the contrary: a number of packages that > ship as a unit upstream are split by Debian into separate packages, so > that portions that are Free and stand-alone remain in main, while > non-Free portions go to non-free, and those that are Free but require > non-Free portions go to contrib. I don’t know of such a package, but if there are, that’s fine. Just unnecessary. > Why should this cleansing not be applied to the kernel, that's > arguably far more important than a number of accessory packages that > undergo this procedure? Because the kernel is perfectly usable without the firmwares. Since they only extend its functionality to support more hardware, there’s absolutely no reason to split the kernel packages. > Please don't frame this as if it were a discussion about dpkg > dependency tags. It's completely immaterial to the discussion which > tag one should use, if any, to represent the fact that some of the > code in a driver requires non-Free firmware code to work. No, the main/contrib distinction comes precisely and uniquely from dependencies (Depends/Recommends vs. Suggests). As long as the package as a whole is free, it can go to main. > The relevant passage is "must not require a package outside of main > for [...] execution". Focusing on the tags comes off as a > distraction away from what's actually stated in Debian's rules, i.e., > it amounts to mistaking a stated consequence (thus, ...) for the rule > itself. Does the kernel require the firmwares in non-free for execution? No. End of story. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: can a kernel in main depend on firmware in non-free to work?
On Oct 28, 2008, Peter Samuelson <[EMAIL PROTECTED]> wrote: > [Alexandre Oliva] >> Say, if these drivers that require non-Free firmware *were* shipped >> as separate packages (for whatever reason), would they really belong >> in main, rather than in contrib? > Now you've hit on it. If they were packaged _separately_, the > drivers that are non-functional without the firmware files would not > go in main. But so long as linux-2.6 is one big package, I hope the prevalent interpretation of Debian's rules and policies isn't so lax as to make room for such manipulation as packaging stuff in main that belongs in contrib or non-free just because it happens to be part of the same upstream package. In fact, I have evidence to the contrary: a number of packages that ship as a unit upstream are split by Debian into separate packages, so that portions that are Free and stand-alone remain in main, while non-Free portions go to non-free, and those that are Free but require non-Free portions go to contrib. Why should this cleansing not be applied to the kernel, that's arguably far more important than a number of accessory packages that undergo this procedure? > the Depends relationship does not make sense Please don't frame this as if it were a discussion about dpkg dependency tags. It's completely immaterial to the discussion which tag one should use, if any, to represent the fact that some of the code in a driver requires non-Free firmware code to work. The relevant passage is "must not require a package outside of main for [...] execution". Focusing on the tags comes off as a distraction away from what's actually stated in Debian's rules, i.e., it amounts to mistaking a stated consequence (thus, ...) for the rule itself. Now, of course, one could argue that the portion that requires non-Free code is not used by most, so the package as a whole works just fine for most users in spite of the dependency. But then again, this kind of reasoning doesn't keep non-Free portions in main or contrib, and since it makes room for blatant manipulation of the rules by packaging tricks, it would probably make Debian's regulations and Debian itself stronger if they wouldn't be interpreted so as to make room for this. But that's your position/decision to make. Me, I'm just trying to make sense of what I see and read :-) Best, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist [EMAIL PROTECTED], gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can a kernel in main depend on firmware in non-free to work?
[Alexandre Oliva] > Say, if these drivers that require non-Free firmware *were* shipped > as separate packages (for whatever reason), would they really belong > in main, rather than in contrib? Now you've hit on it. If they were packaged _separately_, the drivers that are non-functional without the firmware files would not go in main. But so long as linux-2.6 is one big package, the Depends relationship does not make sense - this is why we have the weaker relationships Recommends and Suggests. And we do not require main to be a closure across Suggests. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can a kernel in main depend on firmware in non-free to work?
Sorry that it took so long to respond, I'm not on this list, and I'm not even sure I could/should be. Anyhow, the evidence you presented to support your opinion seems to me to actually support the opposite of your opinion, so please bear with me while I get myself acquainted with Debian's positions and procedures. On Oct 25, 2008, Ben Hutchings <[EMAIL PROTECTED]> wrote: > On Sat, 2008-10-25 at 18:28 -0200, Alexandre Oliva wrote: >> My understanding is that portions of the Debian system that depend on >> non-Free Software, in spite of being Free themselves, belong in >> contrib, not in main. > The relationship from linux-image-2.6.* to firmware-* cannot be > described as Depends or Recommends, So, it doesn't match some of the listed consequences (thus ...) of the rule set forth in 2.2.1. But I don't see that the wording excludes the case at hand: the packages in main * must not require a package outside of main for compilation or *execution* [emphasis mine] And then, 2.2.2 says: Examples of packages which would be included in contrib are: * free packages which require contrib, non-free packages [...] for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs. Now, I don't think one would get very far arguing that a driver that requires non-Free firmware for the device to work doesn't require the non-Free firmware for execution, except in some convoluted and artificially narrow interpretation of execution. Many drivers that require firmware do so at initialization time, and nothing else in the driver ever gets a chance to execute before initialization is complete. And then, just like the GCC driver isn't a compiler per se, it just offers a nicer front end for someone who wants the compiler to run, a driver for a device is just a nice front end for someone who wants the device to work. If firmware is required by the device, this would make the driver in the kernel an accessory to the non-Free program that runs on the device's CPU. FTR, Jeff Carr's understanding of the term firmware comes off as quite narrow, so much so that it doesn't match *any* of the pieces of non-Free firmware that are present in the kernel. That's not to say that initialization sequences without sources don't exist, or that more general hardware configuration information couldn't be held blobs, it's just that his narrow definition isn't relevant to the discussion at hand. Most, if not all, of the blobs that are deemed non-Free are actual programs, that run on the device's CPU. Some are called microcode, some are called firmware, some are called voodoo or ctx_prog, but context makes it quite clear that they're not just register initialization sequences. I've come across register initialization sequences that I had to deem non-Free as well, but not because they were missing non-existent corresponding sources, but rather because they had been copied (by various means) from other programs (most often drivers) without permission, and they were too large to neglect the risk that they amounted to copyright infringement. > because most systems do not require the drivers in question. But is this the correct criterion? Say, would you defend the inclusion of the non-Free firmwares in main just becase most users wouldn't ever run that firmware on their systems, thus making the restrictions imposed by the copyright holders of that code nearly irrelevant for most users? Say, if you had a data compression program that supported plugins for compression formats, and one of the plugin only worked in the presence of a dlopened libraries available in non-free, would this plugin belong in main rather than in contrib, just because the compression format implemented by it was so rare that most systems wouldn't ever run it (or even install it) anyway? Say, if these drivers that require non-Free firmware *were* shipped as separate packages (for whatever reason), would they really belong in main, rather than in contrib? (Note: *some* of the drivers that can load firmware actually work, and get the device to work, without the corresponding firmware, for various reasons. These are some that could quite likely remain in main. It's those that really don't stand a chance of working without the existing firmware that I'm talking about above.) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist [EMAIL PROTECTED], gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can a kernel in main depend on firmware in non-free to work?
On Sat, 2008-10-25 at 18:28 -0200, Alexandre Oliva wrote: > Hi again, > > I've been watching the discussion and the separation of firmware from > kernel sources with a lot of interest, but today it dawned on me that, > even if this project is completed, it wouldn't quite address the issue > of compliance with Debian procedures and regulations. > > I understand main is supposed to be self-contained, and not depend on > software in contrib (or non-free, for that matter). > > My understanding is that portions of the Debian system that depend on > non-Free Software, in spite of being Free themselves, belong in > contrib, not in main. > > If my understanding above is correct, then kernel drivers that require > on non-Free firmware should not be in main, but rather in contrib, and > the non-Free firmware itself (if shipped at all) ought to be in > non-free. [...] The relationship from linux-image-2.6.* to firmware-* cannot be described as Depends or Recommends, because most systems do not require the drivers in question. Therefore linux-image-2.6.* can continue in main without the drivers being separated out, though the sourceless firmware should be. See policy sections 2.2.1 and 7.2. Ben. signature.asc Description: This is a digitally signed message part
