Re: NEW processing during freezes

[Goswin von Brederlow <goswin-v-b@web.de>]

On Thu, Apr 25, 2013 at 09:44:58AM +0800, Chow Loong Jin wrote:
> On 23/04/2013 23:15, Thorsten Glaser wrote:
> > Joachim Breitner <nomeata <at> debian.org> writes:
> > 
> >> The (luxury) problem is that I got used to it and began uploading the
> >> new (and NEW) dependency bar of package foo along with the new version
> >> of foo (instead of uploading bar first, wait for NEW processing and only
> > 
> > I think you shouldn???t do that anyway.
> > 
> > After all, to do that, you???d have to manually install the new version
> > of bar in the chroot you used to build foo, which is a violation of the
> > ???clean, minimal chroot??? rule if read strictly (and, from experience with
> > bad non-buildd uploads, I tend to read it strictly).
> 
> If you use a local APT repository containing "bar", then it still fulfils the
> "clean, minimal chroot" rule, since the debs you have uploaded aren't rebuilt
> for the particular architecture you're building "foo" on anyway (assuming that
> you use the same debs you uploaded to the Debian archive).

By uploading foo with a dependency on a NEW package you make foo
uninstallable for a time. Which on its own is already a bad thing.

Worse it only works if bar is a new source package or you have a
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.

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.

MfG
	Goswin