Rebuilds of binary packages without source changes

[Emilio Pozuelo Monfort]

When there is a transition in Debian, the release team schedules binNMUs for the affected packages so that they are rebuilt with the new transitioned packages.

When there is a transition in Ubuntu, every affected package needs to be re-uploaded by hand, which in case of big transitions (e.g. the recent perl 5.8 -> 5.10 transition) is not nice.

It would be cool if Soyuz had the ability of schedule binNMUs so in case of transitions the release team could do it, which would make transitions happen faster and save time and bandwidth to developers.

[Julian Edwards (julian-edwards)]

BinNMU is forbidden in Ubuntu by policy. Sorry if this is not what you wanted to hear. I can only suggest raising it with the distro team if you want to pursue it further.

[Emmet Hikory (persia)]

Let us instead agree that binary uploads external to Soyuz are forbidden in Ubuntu by policy. While the term used might have been "binNMU", what is sought is a means by which a rebuild may be triggered without source changes. Could there not be a means similar to the existing facilty to rebuild a package that failed to build to rebuild a package when the current binary packages are deemed unsuitable, although the source package is acceptable?

When this is done in Debian, the notation +bN is used as an additional version number for the binary package (with the same version for the source package), where N indicates the number of successful rebuilds the package has undergone. Perhaps a similar mechanism might be used to reversion binary packages internal to Soyuz when such a rebuild was requested.

The permissions model for requesting such rebuilds should probably match that used for requesting rebuilds of packages that failed to build from source.

[Matt Zimmerman (mdz)]

binNMU is a misnomer here. We don't want binary uploads in Ubuntu, nor do we have a concept of NMUs.

The use case here (which, in Debian, is fulfilled by binNMUs) is to rebuild a package for one architecture without changing the source package or the other architectures.

If this sort of rebuild could be provided by Launchpad in a sane way, I don't see why it should be objectionable.

[Julian Edwards (julian-edwards)]

Thanks for clearing that up guys, that does indeed make a lot more sense now.

[Adam Conrad (adconrad)]

Where this is distasteful to me is that "binNMUs" (or whatever you want to call them) end up with binary packages that don't have a matching source package.

Even our backports packages alter the source before building, so the changelogs match, and you can get a source that matches the binaries. A "binNMU"-like mechanism means there will never be a source package 1.2.3-4+b1 that matches the same binary.

In practice, this isn't a huge deal, but it's still untidy and, IMO, the only reason Debian's done it this way is because doing a bunch of sourceful NMUs can make a lot of people grumpy, while we have no real concept of source ownership.

That said, an automated mechanism to rev SOURCE versions for rebuilds (much in the same way that backports currently work) might be less ugly in my mind. Keeping version numbers in step with Ubuntu policy, you'd end up with uploads that looked like:

1.2.3-4 -> 1.2.3-4build1
1.2.3-4ubuntu1 -> 1.2.3.-4ubuntu2

The other reason (besides "ugliness") for the above suggestion is that there are still packages which are not "binNMU-safe", and while Debian tends to catch most of those and fix them, there's nothing stopping us form having Ubuntu-specific packages which are unhappy with mismatched arch all/any builds, and other such whackiness, nor do we currently have (or need) any policy to enforce safety for a mechanism we've never used.

[Scott Kitterman (kitterman)]

So if we want to use it, we should start working on enforcing/fixing now so that when the mechanism to do it is built, the archive will be ~ ready for it.

[Colin Watson (cjwatson)]

There is a reason to want single-architecture rebuilds that don't change the source, beyond Debian-specific issues with sourceful NMUs and source ownership. If you're close to release and discover an issue affecting a single architecture, it is beneficial to be able to fix that one architecture without having to change all the others too (and perhaps run across new and unexpected problems). Even further away from release, it may be desirable to reduce the impact on mirrors when fixing single-architecture issues by means of rebuilds, particularly for large packages.

Revving source versions is what we've always done, be it manually or automatically. It means that all architectures have to be rebuilt in step, increasing general load, and I would much prefer to have a way to rebuild single architectures if possible.

I tend to agree with Scott here: we should start enforcing the necessary restrictions so that we're ready for the mechanism. After all, the restrictions are straightforward enough that they can be checked mechanically with Lintian.

[Colin Watson (cjwatson)]

See also bug 235064.