Re: [Pkg-javascript-devel] Request for policy interpretation: procedure and possible outcomes for naming conflicts
On Wed, May 02, 2012 at 02:12:22PM -0500, Jonathan Nieder wrote: Hi policy editors, In the discussion at [1], Pat wrote to the DPL asking for some mediation in figuring out what should happen to the node command name. No one has offered that mediation (the ctte presumably could do it if asked) but I mentioned that there seems to have been some uncertainty about matters of procedure[2], mostly revolving around policy ยง10.1 and the role of policy in general. Stefano suggested writing to you to request interpretation of policy. Sorry to drag you into this. Thoughts would be welcome, but if you'd prefer to hold off on interpretation until this particular story is resolved, that would be a fine answer, too. The questions (from [2]): - When policy 10.1 refers to maintainers reporting naming conflicts to debian-devel and trying to find consensus about which program is to be renamed, is that consensus among the maintainers of the packages involved or some other group? In other words, is stonewalling an acceptable and viable strategy? The consensus is among the Debian contributors group and not restricted to the involved package maintainers. - Policy says that in the absence of consensus, both packages must be renamed. A number of people have mentioned that that looks like a bad outcome from the users' perspective. When there is a real risk of confusion, renaming both packages avoid any user confusion, so this is sometimes the best outcome. Policy also states that different packages must not install commands with different functionality with the same name. Such packages would have to Conflicts anyway, and gratuituous conflict must be avoided. This is not a waivable requiremrent. If a consensus develops around a solution that does not follow policy, could it be implemented? There is something of a precedent for this kind of question in the transition plan for the gnuit/git-core command name conflict. This was before my time, but if I understand correctly then update-alternatives was used for one release to multiplex between the actual commands and a wrapper script that used command line arguments to figure out which command was meant. Ugly as sin (and not a good technical example here), but it happened because the maintainers of those packages and the release team agreed it was the best we could do. GNU Interactive Tools was in Debian since several releases before Linus GIT was introduced. While the consensus was that git should point to Linus GIT instead of GNU IT eventually, care were taken to provide an upgrade path to GNU IT users with minimal breakage, and this was completed in several releases. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Request for policy interpretation: procedure and possible outcomes for naming conflicts
Bill Allombert wrote: On Wed, May 02, 2012 at 02:12:22PM -0500, Jonathan Nieder wrote: Policy also states that different packages must not install commands with different functionality with the same name. Such packages would have to Conflicts anyway, and gratuituous conflict must be avoided. This is not a waivable requiremrent. As a strawman example, here is what I was thinking of when I asked that: nodejs package adds a nodejs command which behaves exactly like node in Debian (this has already been done) and upstream (working on it). node package renames /usr/sbin/node to /usr/sbin/axnode but keeps /usr/sbin/node as a wrapper that prints a warning and then calls axnode (a patch doing that has been proposed, but Pat has disparaged it as doing too little) Packages depending on nodejs use the nodejs command instead of node (this would be a lot of work, but probably doable) ax25d and node maintainer scripts update configuration to refer to /usr/sbin/axnode instead of /usr/sbin/node (will require ham radio maintainer cooperation) That way: - node and nodejs don't conflict - while there are two node commands, no Debian package uses either - people using the node command with both packages installed know they're asking for trouble and have an alternative available - existing scripts and installations using one of the two node commands are not broken unless the other is also installed - installations with /usr/sbin symlinked to /usr/bin are broken. But I don't think anyone actually does that on Debian systems. Maybe this is not a great idea. My basic question was whether this kind of thing (i.e., potentially ok outcomes not currently permitted by policy) is possible or not worth thinking about at all. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Request for policy interpretation: procedure and possible outcomes for naming conflicts
Jonathan Nieder jrnie...@gmail.com writes: Stefano suggested writing to you to request interpretation of policy. Sorry to drag you into this. Thoughts would be welcome, but if you'd prefer to hold off on interpretation until this particular story is resolved, that would be a fine answer, too. The questions (from [2]): - When policy 10.1 refers to maintainers reporting naming conflicts to debian-devel and trying to find consensus about which program is to be renamed, is that consensus among the maintainers of the packages involved or some other group? In other words, is stonewalling an acceptable and viable strategy? I don't know what the original intent of the provision was, but in general I would interpret statements about consensus to refer to the project as a whole rather than the individual maintainers. The individual maintainers are generally going to be vested in one outcome or another, so asking them to reach a consensus is much harder. - Policy says that in the absence of consensus, both packages must be renamed. A number of people have mentioned that that looks like a bad outcome from the users' perspective. Policy also states that different packages must not install commands with different functionality with the same name. If a consensus develops around a solution that does not follow policy, could it be implemented? I don't know what to say to this, since this question seems exceedingly strange to me. The way we maintain Policy is by consensus, so if a consensus develops around a solution, the answer is obviously yes? Or, perhaps, the answer is obviously no since the same consensus would change Policy and the solution would therefore obviously follow Policy? I don't know if one of those answers is what you're driving for. In general, Policy is intended to make our distribution consistent and to help our packages integrate. The end goal is the Debian distribution, not following Policy for its own sake. Obviously, if we come up with a better solution than what's currently in Policy, we should do that! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
