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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
