On Thu, Jun 08, 2006 at 05:20:44PM +0200, Raphael Hertzog wrote: > On Thu, 08 Jun 2006, Bas Wijnen wrote: > > Because the package (as I understood it, I don't actually know the package) > > doesn't actually function at all for some people. That's not because they > > aren't interested in it, it's because they need non-free stuff to make it > > work. > > Indeed and our job is to help our users who are in this situation. They > want to use their hardware, we have to tell them how they can get it to > work. > > Hiding the script in contrib doesn't help our users. Users who accept that they might need non-free software to use things have contrib (and non-free) in their sources.list. Users who don't want it don't. If this script is in contrib, it is very visible for people who have contrib in sources.list (a Suggests: would be appropriate), while people who don't want to be bothered with non-free things don't see it. This is exactly the kind of thing contrib is for. > > > The split is not justified by any technical need and thus your reasoning > > > is purely ideological. > > > > Of course it is! There is never a technical reason to put anything in > > contrib or non-free. That's all ideological. You make it sound like > > ideological arguments are not "real", and are less important than > > technical ones. I strongly disagree with that. Debian is an organisation > > which provides software which is both technically and ideologically very > > good. Both of these properties should be protected. Putting things in > > main which really belong in contrib "because there's no technical argument > > for putting them in contrib" is damaging the image of Debian IMO. It > > makes people think we only care about technical matters. If that was the > > case, contrib wouldn't exist at all. > > Well contrib serves an ideological purpose that I share: not cluttering the > package database of people who are not interested in installing non-free > software (because they will have to install something non-free to make use > of contrib). So why should people who are not interested in non-free software and own a device which needs non-free firmware to work with the package be bothered with this script? They should simply see "this package is not supported by free software". That's what they want to see if it is true. (I know what I'm talking about, I am such a person. ;-) ) > However extracting a script from a package in main in a new contrib > package doesn't make any sense. You're not thinking what's best for the > user and for Debian, you're only applying a narrow-minded interpretation > of the definition of contrib. Not at all, I am entirely looking at it from a user's perspective, in particular a user which doesn't want non-free software (those people are the reason contrib and non-free exist, so it seems appropriate to look especially at them). I'm saying that those users do not want to see that script. So it must not be in main. They _want_ it to be "hidden", as you call it. It's not a disservice to them to keep it where they won't see it, but a service. > > I wasn't suggesting a new source package. I assumed (and this has been > > confirmed in this thread) that it is possible to create a contrib binary > > package from a source package in main. > > Where has this been confirmed? I've seen a response to http://lists.debian.org/debian-mentors/2006/05/msg00324.html, but it isn't in the archive and I've already deleted it from my local mail box. Perhaps it was only off-list. Anyway, why wouldn't it be possible to put a Section: contrib/... in the binary package part of the control file? Other overrides are possible there anyway. Can someone confirm that this works? > I was convinced of the contrary since main, contrib and non-free are top > directories in the pool and I expected them to be self containing > (sources+binaries). That sounds plausible as well. > > > So the decision is entirely up to the maintainer. > > > > Of course it is. And if the maintainer comes here to ask what to do, > > we're going to give advice. > > Contradictory advice... so it's better (when possible) to come to a > consensus. I agree with you there, but I can't do that alone. ;-) > > > Not at all. We all know what is DFSG and what is not in this case. > > > > It is totally clear that for some people this package depends on (as in: > > doesn't do anything useful without) non-free things. IMO that makes it > > contrib, but others don't seem to agree. In case of such (theoretically > > based) disagreements I think of debian-legal. That thought can be > > completely misplaced of course. :-) > > There's no notion of "contrib for some" and "main for others". Correct. > So the package is in main and should provide the helper script to make it > useful for the largest number of users. Incorrect (IMO). Contrib is not about reaching large number of users. It's about being free. This script makes the package depend on non-free stuff. It totally makes sense that only people who actually care about that (and thus have contrib in their sources.list) should see it. > In any case -legal is not the moral authority of Debian and since the > problem is not license related, -legal is not a list to consult. That's right, so my feeling was indeed completely misplaced. :-) > Actually a new official definition of contrib might be welcome since we're > having discussion about it very regularly (remember ndisplayer?). Good idea. We should write a proposal for that. But perhaps we should first decide what we think about it. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
Attachment:
signature.asc
Description: Digital signature