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]
