[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#353277: ndiswrapper in main



On 3/1/06, Steve Langasek <vorlon@debian.org> wrote:
> The lack of declared dependencies in ndiswrapper isn't a result of trying
> to do an end-run around policy, it's a result of the fact that ndiswrapper
> does not *have* a dependency on windows drivers in the sense that can
> reasonably be represented in the Depends: field -- just as any given library
> is of limited use on its own, yet it doesn't have an ORed dependency list on
> all the packages (+ unpackaged software) that can use it.

Correct.

I was not disputing the headers of the ndiswrapper package.  I was
disputing the assertion that we can't assume anything about how
the software is used.  My assertion was that we must assume things
about how the software is used in order to populate the Depends:
header.

With that in mind, policy on contrib says that contrib is for
"wrapper packages or other sorts of free accessories for non-free programs."
http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

And I think ndiswrapper is "a sort of free accessory for non-free programs."

To avoid another tangent: I'll grant that drivers are system programs,
and are not application programs, and that in the typical case they're
not associated with a specific process id.  For more detail on what programs
are, see http://en.wikipedia.org/wiki/Program_(computing)

> Given that this is how we understand "dependency" every other time we use it
> in the project, I think it would be inconsistent to say that ndiswrapper has
> a "dependency" on an indeterminate but large number of distinct Windows
> drivers.

Ok, we should probably find a different word to describe this
relationship.

Perhaps it could be phrased that ndiswrapper has a need for the presence
of some software which is not available in debian main.

--
Raul



Reply to: