[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Request for policy interpretation: procedure and possible outcomes for naming conflicts

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?

- 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.


[1] https://lists.debian.org/debian-hams/2012/05/msg00011.html
[2] https://lists.debian.org/debian-hams/2012/05/msg00014.html

Reply to: