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

[Sergei Golovan]

severity 558451 minor
thanks

On Sun, Nov 29, 2009 at 4:57 AM, Evan Broder <broder at mit.edu> wrote:
>
> 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.

Yes. These conflicts are intentional. erlang-doc-html together with
documentation itself under /usr/share/doc/erlang-doc-html creates
symlinks to /usr/lib/erlang/lib/*. And since subdirectories names
there include version number then it might be the case when, say two
kernel-* directories are in /usr/lib/erlang/lib. It doesn't prevent
application from running as Erlang searches its bytecompiled binaries
in all subdirs but it could make applications unbuildable if they use
-include_lib(kernel/include/file.hrl) compiler directive because it
makes compiler use one of /usr/lib/kernel-*/include/file.hrl path (I
don't know which one, though compiles assumes that any such subdir is
usable). And there could be some other bugs which I don't know (and
don't want to know also).

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

I always make sure that erlang and erlang-doc-html are built for the
same upstream version. The temporary problems arise only when testing
migration is a bit unsynchronised, so one of the packages goes to
testing a few days earlier.

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

The conflict is introduces to prevent breakage of erlang-* packages.
Documentation itself wouldn't bother me.

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

I don't think that I should care about Erlang packages in Ubuntu.

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

I don't see a bug in Debian here.

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

I don't want to build a single tarball from erlang and
erlang-doc-html. But some time (i think after squeeze will be
released) I'll convert erlang package into version 3.0 with multiple
original tarballs which will remove burden of manual packages
synchronizing. Until that you'll have to live with it.

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

You're right. Documenting the conflict is a good idea, so I'll do that
in the next upload.

Cheers!
-- 
Sergei Golovan