Meaning of Format field in .dsc
Hello,
chatting with aj on IRC, we again come up on the problem of the Format
field in the .dsc file.
In the .changes file, the Format field describe the format of the .changes
file itself. But in the .dsc, we currently use this field to describe the
structure of the source package itself and not really the format of the
.dsc file (which explains why it didn't get a version bump when Frank
added the Checksums-* fields).
This is inconsistent at best and if we want to fix that, we have to do it
now.
We have several options:
1/ We can use Format for the .dsc format and add a new field named
"Kind/Type" (any better suggestion?) describing the type of
source package where valid values would be "diff" (1.0),
"native", "quilt", "wignpen", "git", "bzr".
In theory Format version would be 1.1 since we add a new field to the dsc.
But 1.X and 2.X would be accepted by etch's dpkg-source... so we need to
arbitrarily increase the dsc format to 3.x when we make use of
newer source packages (to compensate for the ambiguity in the code between
dsc format and source package format).
2/ We can continue to use Format for both the dsc format and the source
package format. But we need a simple way to document changes in the dsc
format that don't affect the source package format. Currently there's a
direct mapping between the field and the perl module. Maybe we can change
that so that the minor version number doesn't count in the mapping.
Instead of "1.0" -> "1_0.pm" and "3.0 (quilt)" -> "3_0/quilt.pm" we would
have "1.0" -> "1_X.pm" (and "1.1" -> "1_X.pm"), "3.0 (quilt)" ->
"3_X/quilt.pm".
This is the least intrusive change. It seems logical somehow to tie the
major number with the source package format that are supported while the
minor number can be used to express backwards-compatible change in the dsc
format. And if we have backwards-incompatible change in the .dsc format,
we can always bump the major number of make sure that major number handles
the same package format than the previous one.
3/ Do nothing and keep the problem.
What option do you prefer? Do you have any other suggestion?
I'm leaning towards the second option currently. The first option would
have been nice if we were designing from scratch but we're not in that
situation.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: