Re: mass bug filing for unmet dependencies

[Raul Miller <moth@debian.org>]

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?

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.

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:

> 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.

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.

There's a good chance that you can't see what social contract problems
would occur by combining contrib and main.  But you have to express
understanding of some concepts before it's possible to explain anything
else.

-- 
Raul