Request for policy interpretation: procedure and possible outcomes for naming conflicts
Hi policy editors,
In the discussion at , 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, 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 ):
- 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?
- 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? 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.