Re: Bug#353277: ndiswrapper in main
Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> WHEREAS
I'd like to expand somewhat on my `no' vote. Many of the questions
here were addressed by my earlier messages and I will try to avoid
repeating myself.
> 5. The technical policy in this matter states that: (debian-policy
> 3.6.2.2, section 2.2.1)
As I have said before, this is not `technical policy'. I don't know
where you get the phrase `technical policy' from. Even if the Policy
Manual is largely technical, that doesn't mean that everything in it
is technical.
Whether a question is technical or political doesn't just depend on
the outcome, and it doesn't depend at all on what you call the
documents (if any) that form the basis for the decision. It depends
on the _reasons_ which will govern the decision.
Can you explain to me why anyone might think that there was a
_technical_ reason for ndiswrapper to be in either main or contrib ?
That is, a reason to do with making the system function better, or be
easier to install, or less buggy, or some such ? That's what a
technical reason is, and if there were technical reasons in this
question then it would be a technical decision (and we would be
spending our effort establishing the facts, not chopping semantic
logic). But there aren't.
Another way to look at it is this: we are looking narrowly at the text
of the policy manual. Why are we doing that ? Normally the committee
doesn't take the policy manual as some kind of handed-down guidance.
The committee is in charge of policy, not vice versa, so that the
policy manual doesn't constrain or bind the committee at all (that's
not to say that we should just overturn it willy-nilly of course!).
So, normally we consider first what the right answer is in the
particular situation and if necessary we will rewrite policy to fit.
The reason we aren't doing this is that we recognise that if we
rewrote the section of policy dealing with main vs contrib we would be
making a political decision.
One possible view of the situation is that policy states a political
decision in terms of technical properties of programs, but it's quite
clear that the part we're relying on trying to interpret is at least
badly ambiguous or underspecified given that different people think
that it `clearly' means quite different things !
> 11. The committee endorses the existing policy on the suitability of packages
> for the main and contrib components; and
Surely the existing policy is vague and definitely needs to be
clarified. Otherwise why are we having this conversation at all ?
If the policy needs to be clarified, and it is within the committee's
power to clarify it, then the committee should do so ! So, please
suggest your proposed wording.
Ian.
Reply to: