Stefano Zacchiroli <[email protected]> writes: > That's a very interesting viewpoint for me, because it's kinda dual to > mine. I understand what you're saying and it has its own merits. But > OTOH I see another part of our *current* stance as non honest, the part > where we say that contrib and non-free are not part of Debian, because > for many practical purposes that's simply not true.
It's a compromise, and as such neither side is happy with it. I think we should treat non-free software as part of Debian, but deprecated and discouraged and with large caveats about how we can't properly maintain it, it undermines user control over their own hardware, and we're providing it only because there is no good alternative. You (and others; I know your opinion is common) would like to push it farther away from the project and basically make it a separate, parallel project to Debian. We currently have a compromise that doesn't make either of us happy, but which is livable. I'm going to object to any attempt to move away from that compromise towards your preferred position, just as you're likely going to object to any attempt to move away from that compromise towards my preferred position. :) Right now, non-free is part of the project in some respects: it uses the same upload rights and vetting, the same bug tracking system, the same developers, to some extent the same buildd network, the same mirror network, and so forth. It's not part of the project in some other respects: no or minimal security support, not considered release-blocking, not enabled by default, and partially not auto-built. The reality is that it is part of the project but a second-class citizen. I think that's what we capture right now by saying that it's maintained by the project but is not part of our distribution. We could probably say that more clearly, but I don't think moving away from that compromise is a particularly good idea. (Unless, of course, you all decide that I'm right and we should just treat it as a deprecated and discouraged part of our distribution. *grin*) Bear in mind my background: I fought tooth and nail to use Debian as the primary (and fairly close to the only) Linux distribution for central computing services for Stanford. Stanford central IT, institutionally, doesn't really care about free software. (Well, that's not *completely* true, but management certainly doesn't care about the ideological argument for it.) Now, don't get me wrong: I believe in the ideology of free software myself, and I'm all in favor of supporting it. But insofar as I have to explain or work around practical, concrete problems with running servers that are created by free software ideology, it constantly reopens conversations that start with the question "why don't we just use Red Hat like everyone else?" Those conversations are always stressful and never fun. So I'm a little defensive around changes that would make my job, as a Debian advocate in an organization that doesn't have an ideological committment to our project ideals, even harder. I understand that you want to do this in a way that won't cause practical problems, so this is more in the way of explanation for my kneejerk response rather than a considered objection to your proposal. > Essentially, that statement is true only for who has read it in the > social contract, in a weird sort of self-fulfilling way. What is true > --- and we should pride ourselves with it --- is that contrib and > non-free are not enabled by default. But aside from that choice, often > done once and for all, many of our users would have a hard time > distinguishing which packages (that they use or otherwise) are from main > and which are not. I think there is some common ground here. For example, I think both of these ideas sound fine: > - add debtags facets to classify non-free packages in terms of which > freedom you give up when using it (is it non-redistribution? is it > restriction of use? etc.) > - make vrms ship APT hooks that tell the user about that provided that I can easily disable warning messages with debconf preseeding, APT configuration, or the like on servers where I just don't care. Those sorts of changes feel lower-impact to me than shuffling everything off to a different domain. My concern is that, as part of an attempt to be cleaner and clearer about this, you will recreate all of the annoyances and roadblocks caused by backports.org being a separate project with a separate archive. Merging it with Debian as backports.debian.org was a huge improvement and made my life considerably easier (and I'm sure I'm not the only one). I would be sad to see us intentionally reintroduce that whole class of problems again in a different place. This idea: > making our APT frontend be more clear about the fact that the user is > about to install non Debian software. I think is fine in a different form. I think we want to say something more specific and concrete than non-Debian. Just saying that it doesn't have security support is, by itself, going to be plenty scary. :) Saying that it's non-Debian software implies to the average user that, for example, it may not be signed, or the upload queue may not be controlled or vetted, or that no Debian developer reviewed it, or that no bug tracking system is available, or that normal Debian tools don't work with those packages. We should not imply those things about software in non-free because they're simply not *true*. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
