[buildd-tools-devel] new buildd dependency resolution breaks self depends?

[Wesley W. Terpstra]

On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx <kurt at roeckx.be> wrote:

> As long as the Packages file for the buildds mentions this arch
> all package, no buildd can build it, because it only considers
> installing the latest version.  But it should get removed
> from that file after 24 or 32 hours or something.  In which case
> we'll only see the old version, can install those, and things should
> work from there.
>

I hope what you're telling me is true, because it will save  me a lot of
work! :)

What I don't understand about your explanation: once the new all+i386 .debs
hit unstable, won't the buildds see the new 'all' package in unstable and
thus want to install it in preference to the old 'any' package even after it
is removed from the Packages file? The 'all' package will still be
uninstallable since it depends on the missing 'any' packages.

While I can fix the problem at hand by removing the mlton 'all' package for
an upload,  I see a more troublesome problem on the horizon:

The basis, runtime, and compiler packages should all be at the same version
to compile correctly. The basis package is an 'all' package which includes
the cross-platform bits of the runtime library. The runtime and compiler are
'any' packages with compiled object code.

If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current
problem), any future uploads will see that it has these versions available:
mlton-compiler (= old-version) depends on runtime
mlton-runtime (= old-version) depends on basis
mlton-basis (= new version)
... which I believe means that the old-version mlton-compiler package will
be uninstallable since the old-version of the basis in unstable is hidden by
the new-version.

Have I understood this problem correctly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110329/452d8a7a/attachment.htm>