Re: mass bug filing for unmet dependencies
Raul Miller writes:
> On Fri, Oct 29, 2004 at 08:38:21AM -0400, Michael Poole wrote:
> > So not only is there a runtime dependency from the boot loader to the
> > BIOS, but there is a Build-Depends-like dependency as well. I still
> > see no conflict with the SC or Policy.
>
> I'm not sure if this is because you just plain can't see basic stuff or
> if it's because you're talking about something different from I.
>
> Here's the dependency chain I'm talking about:
>
> [1] The silly dependency on the boot loader stage in the bios
> [2] lilo/grub/...
> [3] kernel
> [4] all software which runs on that kernel
>
> Is that the dependency chain you're talking about?
Yes.
> Or, if you prefer, you can talk about a direct dependency from the bios to
> the kernel and then include lilo/grub/etc in the dependency chain either
> because of their user space tools (which are needed in any practical
> situation) and their build dependency on user space.
I had not considered that. For some functions[1], I believe the
kernel does have to call the BIOS, but most of the time it need not.
It should be possible to remove those features of the kernel to
"contrib," though, so it is not as fundamental as the boot loader's
dependency on the BIOS.
[1]- I think mostly related to power management.
> For example.
>
> This dependency chain was the first case you brought up when you
> introduced this subject line. If you're not talking about this kind of
> dependency any longer, I don't know what you are talking about.
>
> > There are a number of things we cannot do without free software.
>
> Here, on the other hand, I'm guessing that you meant to say exactly the
> opposite of what you said. I'm basing this guess on the following
> sentence:
Yes, I left off a "non-" before "free." To reword: There are a number
of things for which one needs non-free software.
> > Synthesizing HDL onto most FPGAs is an example (free tools tend to be
> > very limited in what they can synthesize for). Without that
> > capability, having source for a lot of firmware doesn't make a
> > difference. If needing a BIOS to build dependent packages is a reason
> > to ignore that dependency, why object to firmwares (or even programs
> > that require non-free compilers)?
>
> We ignore that bios dependency because it's trivial to write the software
> which serves that role, but in most cases practically impossible to
> change the hardware to use the resulting software.
>
> In other words, it's a hardware issue, not a software issue.
The people at linuxbios.org seem to show that making the hardware use
a new BIOS is not such a problem; but their status page suggests it is
sufficiently buggy that Debian would not want to support it. That
contradicts the assertion that writing the software is trivial.
> To revisit your first point, it would conflict with the social contract
> to treat this as a real dependency because moving everything in main
> into contrib would be a disservice to the free software community,
> and to our users.
>
> Basically, there wouldn't be a debian system under social contract 1.1
> if you had things your way.
To reword, you think we should ignore an otherwise valid dependency
because to consider it would make the Debian system empty. If so,
fine; I think it is hypocritical, but I can accept that. That kind of
logic is what I meant by my earlier email about having stricter
requirements than the license(s) only with good reason.
Michael Poole
Reply to: