Re: NEW processing during freezes
On Thu, May 02, 2013 at 11:31:54AM +0200, Andreas Beckmann wrote:
> On 2013-05-02 11:06, Goswin von Brederlow wrote:
> > versioned Build-Depends on the new version. Otherwise all buildds will
> > simply compile the new foo against the old bar and then you have one
> > arch where foo is uninstallable while all others work.
> This is quickly "fixed" by doing a binNMU on the uploaded-arch.
> People do this all the time: upload packages built against local packages,
> experimental or even on Ubuntu to Debian sid.
> Rebuilding against the NEW package can be done by binNMUs (with proper
> dep-waits), but that very much smells like a transition that is to be
> handled by the release team.
*shiver* Some people are realy broken.
> > Maybe this calls for an upload manager or a dependency based delayed
> > upload queue. You can prepare and sign the upload at any time after
> > all. Only the upload itself needs to be timed to the NEW processing.
> That will only work if the "delayed" package adds a versioned B-D on the
> NEW package (so it comes with an explicit dep-wait), otherwise it will
> be uploaded after NEW processing, but before the NEW package was built
> everywhere. And rebuilding the "old" package may have higher precedence
> than building something completely NEW on architecture $slow.
No, if the package has a versioned B-D then the buildds already do the
right thing and the delayed queue would be pointless.
I was thinking more of something that detects the depends on the
uploaded binary and figures out you build against a too new version of
a lib or of uploading a command file along with the package that says
what to wait for.
The queue would have to scan the Packages.gz files (hopefully
including incoming to minimize delays) to decide when to upload a
package. Going just by Sources.gz would defeat the purpose again.
Another usefull feature would then be for the queue to notify the
uploader when a package being waited on failed to build. Otherwise the
upload would wait forever.