Re: can a kernel in main depend on firmware in non-free to work?
On Oct 30, 2008, Josselin Mouette <joss@debian.org> 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 oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Reply to: