Deal with 3.0 source packages

[broder]

It looks like the Debian community is starting to slide towards making the 3.0 source package format the default. Today I noticed that the missing-debian-source-format Lintian tag was upgraded from "Info" type to "Warning":

dpkg-buildpackage: source only upload: Debian-native package
Now running lintian...
W: debathena-printing-config source: missing-debian-source-format

I haven't heard anything about an actual time line for the turnover, but this is something we probably don't want to be caught by surprise with - as soon as dpkg-source on zulu starts building 3.0 packages by default, our build chroots will stop being able to unpack the chroots.

Given that we need our source packages to build on old releases, I think at this point we may need to go doing mkdir -p debian/source && echo 1.0 >debian/source/format in all of our packages.

[broder]

It looks like one option would be to force dpkg-source to generate version 1.0 packages by putting something like the following in ~/.devscripts:

DEBUILD_DPKG_BUILDPACKAGE_OPTS="--source-option=--format=1.0"

(along with whatever other options you want passed to dpkg-buildpackage by default)

This makes debuild pass --source-option=--format=1.0 to dpkg-buildpackage, which makes dpkg-buildpackage pass --format=1.0 to dpkg-source, which makes dpkg-source always build a 1.0 source package.

All that aside, it seems sketchy to me to change how our packages build as a function of whether they're building on our build servers or not - i.e. anybody running with a sufficiently new dpkg on their own machine would get a 3.0 package.

[andersk]

It changes how our source packages build, not how our binary packages build—but that’s already the case, since we already set DEBUILD_DPKG_BUILDPACKAGE_OPTS="-sa -us -uc -i". And I think, in the unlikely event that someone not-us builds a Debathena source package on Squeeze and can’t extract it on Hardy, they’re probably running a build server, know what they’re doing, and will be able to figure out what’s wrong.

However, the Debian wiki  claims that “The plan to change the default source format has been dropped. Instead it is planned to make debian/source/format mandatory at some point and to not have any default format.” If that’s true, this would … be a good reason to add one.

But given Debian’s glacial release cycle, I’m guessing we won’t have to worry about that for a long time. If Hardy is desupported first, we might actually want to think about moving to 3.0 instead of forcing 1.0.

Meh.

[jdreed]

Replying to andersk:

If Hardy is desupported first [...]

So this happened. Should we move to 3.0? I have read the wiki and am still confused. It sounds like we choose either 3.0 (native) or 3.0 (quilt) depending on whether it's a native package or not, and additionally if we change edit anything outside debian/ we turn that into a separate quilt patch?

[amu]

choose either 3.0 (native) or 3.0 (quilt) depending on whether it's a native package or not

Right.

if we change edit anything outside debian/ we turn that into a separate quilt patch?

Alternatively, you can create a debian/source/options containing the line single-debian-patch to indicate that a traditional single patch is still appropriate, for instance because all changes are in a public VCS repository anyway. (My own packages take that approach.)

[achernya]

We should try to move as much to 3.0 (quilt) as possible, with the exception for the metapackages, which can be 3.0 (native). After we do that, we should upload to athena-dist.

[jdreed]

We haven't yet figured out how the workflow happens with debian branches, and that's a pre-req for moving to 3.0 (quilt).

[jdreed]

Victor is doing this as he converts the packages to gbp.