Re: mass bug filing for unmet dependencies (Was: firmware status for eagle-usb-*)
Raul Miller writes:
> > > Note that we do treat dependencies on software we do not distribute as
> > > real dependencies.
> On Thu, Oct 28, 2004 at 01:20:12AM -0400, Michael Poole wrote:
> > In the goal of seeking consistency, I think this requires mass bug
> > filing against packages with unmet dependencies, including:
> We have traditionally ignored boot loaders because they're outside
> our scope. The reason they're outside our scope is not because we don't
> treat them as software but that we can't take control of a system without
> using a boot loader.
"We do it that way because it's not practical to do it the other way"?
Except for GR 2004-004, when has that been good enough to ignore the
SC? Will you propose a GR that we should ignore (for now or forever)
the dependency of boot loaders on the BIOS?
> For the rest to be relevant to the firmware discussion, the examples you
> mention would have to be cases where we are dealing with the requirement
> targets as if they are software.
"We do it that way because that's the way we do it"? The SC is
specifically not limited to software; that was what GR 2004-003 was
about, and that was an editorial change: it was supposed to clarify
the meaning, not change it.
It is not consistent to claim that programmable software on a BIOS
flash chip is not software, but programmable software in an FPGA is
software. It is not consistent to claim that a driver depends on
software on the other side of a hardware bus but that gaim does not
depend on software on the other side of a network.
> However, note, that it's fairly easy to throw together a server which
> serves some protocol -- this tends to be much easier than throwing
> together a new piece of hardware. So, in most cases, if there is any
> validity to your bug reports it's quite likely that that could be resolved
> reasonably quickly without changing any debian package. In many cases
> (tcp protocols where adequate documentation exists), all that would be
> required is a simple shell or perl script running under inetd.
> That said, I've not gone over all these cases in detail and there
> might be some cases where your proposed bug reports have some validity.
> [These would be cases where documentation is inadequate to easily and
> quickly put together a free implementation of a server for one of these
Strictly speaking (since the arguments about firmware rely on strict
interpretations), the dependency is not satisfied merely by the
existence of some free server implementation. It has to be part of