Re: transition binNMUs
On Thu, 2006-01-12 at 17:21 +0100, Julien Cristau wrote:
> On Thu, Jan 12, 2006 at 16:08:05 +0000, Stefano Zacchiroli wrote:
>
> > On Thu, Jan 12, 2006 at 02:43:01PM +0100, Julien Cristau wrote:
> > > some packages have been binNMUed by the release team for the 3.09.1
> > > transition, and so don't need to be reuploaded:
> >
> > As I already observed elsewhere all those packages must have an RC bug
> > filed against them for not respecting the debian ocaml policy.
> >
> Well, I still don't understand why this is so wrong in your opinion.
The problem is that *Debian* is broken. The strict dependencies
are a hack to fix this.
Really we need that library XYZ-3 source package, depending on
library ABC-5, built with Ocaml-3.09.0-4, should produce binary
package
XYZ-3-Ocaml-3.09.0-4
depending on ABC-5-Ocaml-3.09.0-4: in other words the
dependencies of the binary libraries depends ALSO
on the binary version of Ocaml used to build it.
Interestingly this is also the case for bytecode applications
needing libraries, but it is is NOT the case for native
code applications (the library is linked in already, so
there is a build dependency but not a (nonbuild) dependency).
Had this technique been used for C++/gcc the whole massive
mess of recent times with libstdc++ would have been avoided.
The point is: it is the Debian system itself which is broken,
it does not manage dependencies very well at all (so much
for 'advanced package manager' when it can't get even basic
maths right).
The problem is basically debian-ocaml-maint don't want
to clutter the user with all these library versions,
and in particular, multiple installations of Ocaml,
which do not conflict (provided every one and all its
libraries live in different directories AND all the
executables have suitably distinct names).
Of course that would break heaps of scripts so you'd
also need links for 'current toolkit set'.
And since usually you would only want one such toolkit,
all the kits are named the same and their binary versions --
instead of being marked incompatible or being separately
installable -- just clobber each other without any interlinking.
So the job falls on debian-ocaml-maint to make sure the whole
suite is coherent -- because there is only one, most current one.
The PROBLEM -- in my opinion anyhow -- is that Debian itself
cannot handle this. It has to be done by a bunch of DD's manually.
This is just a bug in Debian, that the policy debian-ocaml-maint
chooses can't be automatically maintained by the archive itself.
Crudely -- the archive manager is too dumb to be able
to know when to instantiate abstract relationships.
It may not matter much for Ocaml with small number of users
and packages, but it held up the release cycle of the whole system
due to C++ for example for MONTHS -- so it does matter.
Bottom line: source code dependencies should NOT be
reflected in binary dependencies -- they should be
INSTANTIATED with the complete set of build tools used.
THEN the dependency graphs would be correct. In particular
the build tool dependencies would reduce the graph,
eg if gcc-A and gcc-B produce compatible binaries,
the system would know about this.
The point is: the dependencies are NOT solely declarative
as they should be to allow automation: they depend also
on mutable state effected by the uploading team.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Reply to: