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

Re: Bug#353277: ndiswrapper in main



Thomas Bushnell BSG writes:

> Michael Poole <mdpoole@troilus.org> writes:
> 
> > It has been argued in this thread that if ndiswrapper were put in
> > main, it would mean that contrib has no point at all.  One could
> > equally well argue that if ndiswrapper were put in contrib, main would
> > have no point at all.
> 
> I'm afraid that's not an answer to my question.

It wasn't intended to be an answer to your question, just a reminder
that actions have consequences.

> > There are benefits to users for putting software into the "innermost"
> > category for which it qualifies; consciously putting a package in
> > contrib when it could go into main raises questions of *why* it was
> > put in contrib -- and which other packages might get the same
> > treatment.  If putting it in contrib were simply an accident, then
> > that bug could just be fixed with no policy implications.
> 
> You are suggesting that there is some "mistreatment" in putting a
> package in the wrong category.  As in "might get the same treatment".
> 
> Is the idea that you somehow wound the ego of a package by putting it
> in contrib?  That surely isn't right, of course.  But I'm stuck for
> wondering.  If a package is wrongly put in "lib" when it belongs in
> "libdevel", for example, or vice versa, there is no huge flame war,
> nothing bad happens, we just carry on.  Such a state could continue
> for years without anybody getting upset or much caring.
> 
> I just *assume* that errors in categorization will be made.  That
> doesn't mean errors are good, of course.  But my question is: what
> *harm* does this particular error (if it is an error) cause?

Under the default configuration the last time I installed Debian, the
contrib section is not used; arguing that some future technical change
might change that behavior leaves the issue open until that change is
actually made.  Fixing a main->contrib error is likely to require much
greater effort and debate than a libdevel->lib error, since Policy
defines the distinction between main and contrib but not the one
between libdevel and devel.  Personally, the effort to fix the error
is why I prefer to decide a grey area sooner rather than later.

The suggestion that wrongly putting a package in contrib is the kind
of error that one can live with seems like little more than a way to
push it into contrib without addressing the question of whether or not
it actually belongs there.

Michael Poole



Reply to: