* Neil McGovern [2012-06-04 11:27 +0100]: > On Sun, Jun 03, 2012 at 10:45:51PM +0200, Carsten Hey wrote: > > The last paragraph of [1] suggests that there is no technical conflict > > between the maintainers of both packages. All that would have been > > needed after the communication problem was solved is a technical > > solution that makes all happy and the release team and the ftpmasters > > agreeing to ignore the according policy violation. Anyway, now the > > technical committee is in the game and I assume the release team would > > not create facts whilst the TC is discussing this unless it is asked by > > TC members. > > I'm not sure what you mean about the release team creating facts,
If the maintainers of node and nodejs would have agreed to a technical solution that complies with the Debian policy, then there would have been no need to involve the technical committee at all. If there would be a technical solution both parties would agree too that violates the Debian Policy, but is despite this policy violation accepted by the release team and by ftpmaster (the release team to accept the packages in Wheezy and ftpmaster to accept the packages in the archive - or less abstract, to tag a hypothetical bug wheezy-ignore and to let the packages pass the new queue), then I think there would be no need for a TC ruling too. Before May it was not possible for people that weren't involved in maintaining of any of the affected packages to find a technical solution that has a reasonable chance to be agreed upon by both maintainer teams, the release team and ftpmaster. Due to the great way Pat recently participated in the discussion and the additional information he provided, finding such a technical solution that has a reasonable chance to be agreed upon became possible. Nearly at the same time the technical committee was asked for a ruling. This is the situation we now have. There are possible consensual policy violating technical solutions and valid arguments for the position that the policy would be violated in its wording, but not or only partly in its intension. The maintainers did not yet agree, but I think they would. Now that the TC is involved and already discussed this conflict, it might prefer to rule over it, instead of being bypassed by the release team and ftpmaster (I'd assume that ftpmaster follows a decision of the release team - but this is only guesswork). This bypassing the TC is what I meant with "creating facts". > I'm not aware of any approaches by the maintainers or others asking > for any opinions from the release team. There weren't any approaches to ask the release team. I did not do so to avoid bypassing the TC. The rest of the mail mainly summarises the problem and the technical solutions. The policy violation is the conflict of programs in different packages with the same filename, as described in the policy section 10.1 (the policy wording is that strict to force people to find a consensus). One reason to prohibit this is to avoid artificially limiting the combinations of programs that can be installed at the same time. An other reason mentioned recently on this list is to ensure that users can expect that one program name always refers to the same program in Debian. The technical solutions involve compatibility packages that ship a symlink to the real program name. I'm aware of two reasonable kinds of such packages: * If a command and the binary package is renamed between releases, the later release can ship a package with the old name that provides the symlink 'old name' -> 'new name'. This ensures smooth upgrades and provides the user as much time as required to migrate local scripts. Drawback is that the user is not able to install the package that provides a new program under the old command name, i.e., a node user wouldn't be able to install nodejs without breaking local scripts before they have been migrated to use ax25-node as program name. All known possibly consensual technical solutions involve such a package 'node' and in my opinion it should only be part of one Debian release. * Debian uses a command name that is uncommon on other systems for a program. To provide users an easy and robust way to access this program under the more common name, Debian provides a -compat package that ships this command as symlink (-legacy was used in the draft, but I assume that this is a relict from a time where we hoped to convince nodejs's upstream). Since both kinds of packages only provide a command name via symlink, they do not artificially limit the combinations of programs that can be installed at the same time. So this part of the reasoning behind the policy is not violated. If ensuring that that users can expect that one program name always refers to the same program in Debian is reasonable even if non-Debian systems ship with an other program name, if the reverse is sufficient (that is, a program must be referred by one unique name), if exceptions are only accepted if the command name is only provided by symlink-only packages or if this does not matter at all is possibly a key question in choosing among the possible solutions. Either nodejs provides /usr/bin/nodejs (which would not be agreed to by node's maintainers), or it provides /usr/bin/node and /usr/bin/nodejs, or it only provides /usr/bin/nodejs and /usr/bin/node is provided by nodejs-compat, or it provides /usr/bin/node. The question that could avoid the need for a TC ruling is if the release team would accept such a symlink providing package (or packages in one variant) in Wheezy despite the policy violation. It this would be accepted, an ACK from ftpmaster and both maintainer teams would be needed to finally solve this. Doing this without anyone from the TC agreeing that bypassing the TC in this way is fine doesn't appear to be the right way to handle this issue. Regards Carsten -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
