[Pkg-erlang-devel] Bug#558451: erlang conflicts with erlang-doc-html is problematic

[Evan Broder]

Package: erlang-base
Severity: important

erlang-base, erlang-base-hipe, erlang-appmon, erlang-common-test,
erlang-corba, erlang-crypto, erlang-debugger, erlang-dialyzer,
erlang-docbuilder, erlang-edoc, erlang-et, erlang-eunit, erlang-gs,
erlang-ic, erlang-inets, erlang-inviso, erlang-megaco, erlang-mnesia,
erlang-observer, erlang-odbc, erlang-os-mon, erlang-parsetools,
erlang-percept, erlang-pman, erlang-publickey, erlang-reltool,
erlang-runtime-tools, erlang-snmp, erlang-ssh, erlang-ssl,
erlang-syntax-tools, erlang-test-server, erlang-toolbar, erlang-tools,
erlang-tv, erlang-typer, erlang-webtool, and erlang-xmerl ALL conflict
with erlang-doc-html when the upstream version of the latter is
different form the upstream version of erlang itself.

However, since erlang-doc-html is in a separate source package than
erlang (and therefore not uploaded or included in the archives
simultaneously), this can easily result in a state where
erlang-doc-html is uninstallable.

While I assume that such a conflict is to ensure that documentation is
never out of sync with the actual erlang langauge, I find it hard to
believe that the desire for such synchronicity is SO STRONG that users
should be restricted to either the EXACTLY correct docs, or none at
all.

As particular evidence of the problem, Ubuntu has now for multiple
sequential releases synced in a new version of erlang after the freeze
of automatic Debian imports without syncing the corresponding version
of erlang-doc.

Ubuntu Jaunty has erlang 1:12.b.5-dfsg-2 and erlang-doc
1:12.b.3-dfsg-1.

Ubuntu Karmic has erlang 1:13.b.1-dfsg-2ubuntu1 and erlang-doc
1:13.b-dfsg1-1.

If there's a technical reason that the two packages must be kept in
such tight lockstep, that suggests to me that they should actually be
a single source package, instead of two. But I believe the better and
more maintainable solution is to just drop the conflicts entirely.

In addition to the practical annoyances these conflicts present for
Ubuntu, they are also arguably minor violations of Debian Policy. Most
notably, Debian Policy says that packages with Conflicts SHOULD
explain and justify those Conflicts in the package description. The
Policy also states that Conflicts entries should "almost never have an
'earlier than' version clause".