On Mon, Aug 28, 2017 at 09:15:01AM -0400, The Wanderer wrote: > On 2017-08-28 at 07:59, Dr. Bas Wijnen wrote: > > I think if someone wants to write a client with the purpose of > > interacting with a non-free service, that client should go in contrib > > and there is nothing wrong with that. I find the obsession that some > > people seem to have with getting their software in main startling. > > Why should software be in main if its purpose is to work with > > non-free software? That's exactly what we have contrib for. > > One plausible rationale for this is accessibility to end users, and that > goes back exactly to your other point about what repository > configuration should be the default. Agreed. Now as far as I know, in Debian we try not to use dirty workarounds, but fix bugs when we find them. In this case, the bug is that many users need software from contrib or non-free (especially now that we have properly put lots of firmware in there), but it's rather hard to get to it. Should maintainers work around that problem by putting packages in main even if they don't belong there? Or should we fix the actual problem and make contrib and non-free more easily accessible? As long as almost essential firmware is in there, I think they should be enabled by default. And once that issue is fixed (by creating a separate firmware section, for example), I think we should still make it easy to enable them, both at install time (there should be a question about enabling them in the installer; I thought there was, but it's been a while since I ran the installer) and on an installed system (I know Ubuntu has a graphical tool that allows enabling and disabling sections; doesn't that tool work for us?) In short: the fact that quite a few maintainers are trying to push their contrib packages into main should be fixed by making it easier for users to install packages from contrib. I am surprised that this is so controversial. > There's also the fact that it's repeatedly stated that anything not in > main is not part of Debian; it's easy to see why a maintainer would want > to have a package in Debian, rather than having it be a second-class > citizen. But that's the way it should be. Debian is a self-contained free software operating system. If you install things from main, it will not tell you that you need stuff that isn't in main in order to use those things. If you find a problem with your software, you know that you can get the source code from our repositories and fix the problem. If a client requires communication to a non-packaged server, then the bug you are seeing could be on that server and you cannot get the source for it from Debian. That is an experience we tell our users they will not have. Again, it surprises me that the same people who don't seem to care all that much about freedom and happily make their package depend on a non-free server, have such strong opinions on which section of Debian their software should be in. The fact that contrib and non-free are not a part of Debian is because we care about software freedom. How can you say "this software really needs to be in main, not contrib", but at the same time say "I'm indifferent to whether or not the software depends on non-free stuff"? That like saying "I don't care what text editor you provide me with, but I hate you if it isn't gedit". How is it not obvious to everyone that this is a contradiction? Obviously those people care a lot about what section their software is placed in, but they don't want to follow the rules that come with the section placement. We should explain to those people that if they want to be part of the self-contained free system that Debian is, they must follow the rules that we made for it. If they think those rules are stupid, then they should ignore the sections and accept when we sort their package into contrib or non-free. > Perhaps adding that 'firmware' repository and enabling both it and > contrib by default, while keeping non-free disabled by default, would be > the most optimal solution? Although that would seem to imply a change in > what is considered "part of Debian", which might be controversial. I think we should do that (and until there is a firmware repository, also non-free) and I don't think it's a problem. Having a link to a network service in our system does not make the target of that link part of the system. Everyone who claims that requiring a non-free and/or non-packaged server is acceptable for a package in main should certainly agree with that. Just having contrib and/or non-free enabled doesn't mean we are requiring them, so that isn't a problem either. And if even people like me agree with that, I think it is to be expected that there is consensus about it. On Mon, Aug 28, 2017 at 10:18:02PM +0200, Tollef Fog Heen wrote: > The value of an ICQ server with a singular user is pretty low. The > value there lies not in the software itself, but the network effects and > the people you can talk to. > > Likewise, a lot of the value in using various cloud services is not in > the software implementations. It's in how they are run, that there's > «always» capacity available and so on. > > I think this is important, because those are attributes that can't be > packaged. Having the source (and redistribution rights) to some cloud > provider's software would not really put us that much closer to having > what they offer and make them attractive. While this is true, it doesn't mean there is no value in a free server implementation. If an organization finds a client in Debian and wants its people to use that client internally, they should be able to set up their own server for it. Both the desert island and dissident tests (while not really applicable since this is not a license freedom question) show that it is not acceptable to tell them "you must use the server that is available on the internet". So if a free client depends on a server and nothing that is packaged can provide that server, then it seems obvious to me that this requirement means that the package belongs in contrib. On Wed, Aug 30, 2017 at 01:51:16AM -0400, Anthony DeRobertis wrote: > On 08/29/2017 03:25 AM, Carsten Leonhardt wrote: > > Actually, I haven't seen anyone citing the following part of policy > > 2.2.1: "None of the packages in the main archive area require software > > outside of that area to function." > > > > If we agree that "functioning software" does more than print an error or > > a usage note, this part makes it rather clear where free client software > > to non-free server software belongs. > > It also would apply to anything where the server isn't packaged (in > main)—whether or not a free server exists.. The plain wording of Policy > requires that the server (if it's required for the client to operate) not > only be free, but also be packaged in main. > > That clearly doesn't match historical or current practice. Actually, that isn't so clear at all. At least when it comes to current practice, I have yet to find any client for which nobody wrote a free server. People keep implying that we have many such clients currently in main, but I don't think we do. So there is no clear current practice that can be used as an argument. Historically there may be more truth to this, but I don't know the history very well so I don't know. However, I wouldn't be surprised given the way we handle firmware has changed over time. On the other hand, I think that is also a reason to say how we handled other programs in the past is not so relevant: apparently we have changed how we treat this issue. > Policy is not the Social Contract, Policy is not the Constitution. Policy > can be relatively easily changed and is supposed to largely document actual > practices. So really, Policy needs to be amended. And attempting to > language-lawyer Policy like this is pointless. Agreed. I have tried to make this clear, but didn't state it as clearly as you did here. The problem is that the hard rule we're talking about is SC#4, and that is too vague to draw conclusions from about this issue. So what we as a community think about it matters. On Wed, Aug 30, 2017 at 04:58:33PM +1000, Ben Finney wrote: > Yes, I'm in agreement that the Policy wording has not been demonstrated > to cause the alleged problems. There have been people (including you) saying that the list of package dependencies is the scope of the requirement, while others (including me) have said it is just an example and other ways of requiring are covered by the statement as well. Obviously it is not as clear as it should be. > I'm also in agreement with Anthony that, *if* the Policy wording is in > conflict with agreed consensus practice, in that hypothetical scenario > that would mean it is Policy that need to change. Yes, I agree with that as well. For this reason I'm not trying to tell anyone that they must believe policy, but rather that the spirit behind it (requiring non-packaged software means a package cannot be in main) is what counts. You seem to be disagreeing with me that this is what the spirit of the rule is, and/or that there is consensus about this. So let's be clear here: You think there is consensus that the rule should really be that a package can be in main if it is free software and all its dependencies are also in main, except for dependencies which run on a different computer, and those dependencies not only don't need to be in main, they don't even need to be free software? I would be very disappointed in our members if we agree to that. Thanks, Bas
Attachment:
signature.asc
Description: PGP signature