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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[I originally sent this to Peter directly, my apologies.]

> I think you'd be pretty hard-pressed to find
> anyone who would consider it "useful" to print an init message to the
> kernel log, use up a bit of memory, and do absolutely nothing else.

I'd find it useful for the functionality to be there when I wanted to
load a driver with it. What kind of driver (supplied by me) I chose to
load with it should be my decision as a user, not Debian's. Debian's
policy should govern things it ships, not the data (executable or not)
a user might want to feed to a program. (Others in this thread have
come up with examples like open file format viewers with no
in-the-wild documents yet, programming languages without code written
in them, ...)

Even if there was a sentence like "All software in Debian main must be
useful within a pure free software environment." in a binding
document, that still leaves objective criteria for "useful" to be

> In some cases you are correct, "useful" is hard to define, so one has
> to be lenient.  This isn't one of those cases.

Something that needs to be decided case-by-case basis, possibly
leniently, is subjective. (Except of course you have objective
criteria for all cases, but that's a catch-22.) However, the
main/contrib distinction should like the free / non-free distinction
be as objective and transparent as possible.

> > (IMHO something is shown to be useful if a developer finds it worth
> > their time to create and maintain a package, but that's just me.)
> Well, until you find out whether the maintainer would have considered
> ndiswrapper "useful enough to create and maintain" if it could only be
> used with free drivers, or if it didn't support any drivers at all,
> this distinction doesn't help.

I'm sorry but I don't understand this sentence. I'll try to explain
what I meant. If a developer files an ITP for a package and that
doesn't get shot down by heated flames, if that developer then
actually prepares a functional package - doesn't that show in itself
that the package is useful? When all else is equal, except main or
contrib, isn't it a little late to ask if the package is useful? When
a package isn't useful, why have it at all?

I stand by my opinion that usefulness is in the eye of the beholder.

> Moving something from contrib to main, when its status changes due to
> additional free software becoming available, is NOT HARD.

No, it's not technically hard, it's just confusing, especially in the
other direction. ndiswrapper is in main. Maybe it will be moved to
contrib as a result of this discussion or of a decision by the
technical committee. Maybe it will be moved back and forth a few
times, with a heated discussion each time, who knows? Doing it isn't
hard, but doing it in regular intervals for every package thus
disputed is surely undesirable.

> I mean, as well worry about all the software we label as "Priority:
> extra". That's another arbitrary line to draw, judging a package by
> its degree of usefulness to most people.

Yes, that's true. However what I'm saying is just that main vs contrib
shouldn't be arbitrary, nor does it say anywhere that main and contrib
should be differentiated by the usefulness of their packages.

> We think our users deserve free
> software, partly to avoid that very problem, so we use 'contrib' to
> label the contents of the archive that may suffer from these
> restrictions.

Is the definition of contrib then something like "free software that
shares some of the undesirable traits of non-free software due to the
fact that it closely integrates with a non-free component?" Nice,
actually, if someone who's better than me with words made proper
sentence out of it. Would put ndiswrapper firmly in contrib.

I guess im just incredulous that Debian, which has clear and concise
rules about almost everything, doesn't use a simple checklist to
determine if something goes in main or contrib.



Reply to: