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]
