Re: node (was: IRC Meeting (Thursday, May 31, 2012) Notes and Logs (Time in PDT))

[Carsten Hey <carsten@debian.org>]

* 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