Bug#986152: Offer of help

[Roberto C. Sánchez <roberto@debian.org>]

On Sat, Jan 21, 2023 at 09:58:13AM +0100, Romain Francoise wrote:
> On Fri, Jan 20, 2023 at 11:59:44AM +0000, Jeremy Sowden wrote:
> > The Developer's Reference, § 5.6.1, expresses the preference that when
> > new binary packages are added to a source package, it should be
> > uploaded to experimental, so I've updated the version and distribution
> > in the change-log entry accordingly.
> 
> But these are not *new* binary packages, so I don't think the upload
> will go through NEW. In fact, I hope it won't because there's still the
> freeze to consider and I'd really like the new package to be in
> bookworm.

Sort of.  Whenever a source package produces a new binary package,
whether that package exists in the archive already or not, it will land
in NEW.  For instance, this happens with libraries that bump SONAME and
start shipping a new binary package as a result.  Consider the source
package foo which produces (among others) libfoo1.  If the SONAME is
bumped to 2 causing libfoo2 to be emitted by the foo source package
instead of libfoo1, then that upload will land in NEW.  The FTP masters
take notice and this particular case is usually handled very quickly
(since they don't have to do all the normal checks of a brand new source
package), but they still have to check that the new binary package being
created by the source package in question doesn't conflict with a binary
package from another source package.  Imagine an entirely different
source package, foo2, that already produced the binary package libfoo2.
Allowing an unchecked upload of foo to add the libfoo2 binary package to
the archive when foo2 is already producing a libfoo2 package would be a
Bad Thing(TM).

This is where appropriate use of things like Breaks/Replaces/Conflicts
can help streamline the process.

Regards,

-Roberto

-- 
Roberto C. Sánchez