severity 558451 minor thanks On Sun, Nov 29, 2009 at 4:57 AM, Evan Broder <bro...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
