Ticket #579 (assigned defect)

Opened 11 years ago

Last modified 7 years ago

Deal with 3.0 source packages

Reported by: broder Owned by: vasilvv
Priority: normal Milestone: The Distant Future
Component: development Keywords:
Cc: Fixed in version:
Upstream bug:


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.

Change History

comment:1 Changed 11 years ago by 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:


(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.

comment:2 follow-up: ↓ 3 Changed 11 years ago by 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.


comment:3 in reply to: ↑ 2 Changed 8 years ago by 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?

comment:4 Changed 8 years ago by amu

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


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.)

comment:5 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by 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).

comment:7 Changed 7 years ago by jdreed

  • Owner set to vasilvv
  • Status changed from new to assigned

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

Note: See TracTickets for help on using tickets.