On Sat, Mar 01, 2008 at 06:19:47PM +0100, Raphael Hertzog wrote: > > Sounds like you shouldn't be naming them after the version number then. > > Having Dpkg::Source::Package include `native', `origdiff', `wignpen', > > `git', `bzr', would seem more sensible; then you'd just need to delegate > > to them directly. > Yeah, this crossed my mind too. On the other hand, there's quite some > code to handle the various -s* options that I' like to mostly deprecate > for newer Formats (partly because they are useless, and partly because > their meaning is not very clear when we have multiple orig tarballs). It seems pretty simple for dpkg: if it's of the form <src>_<upstream>.*, treat it as .orig, if it's of the form <src>_<upstream>-<debrev>.*, treat it as the diff. For the archive, you might want to ensure a -2 upload doesn't introduce more/different .orig sources than the -1 upload; but we already do that anyway, in the form of ensuring that we don't get a new .orig with different contents. But that's not dpkg's problem, afaics. > Currently this compatibility code is restrained within V1_0.pm and with > such a solution we'd have to put it in all modules that handle Format: 1.0 > source packages and make it conditional on the announced format. Limiting the code to the native and origdiff formats would work just as well, afaics. I would've expected it to already be present in V2_0.pm/wignpen as well though. > > > I'd be satisfied with that but I'm wondering if we have to handle > > > native packages in Format: 2.0 too ... > > Hrm, I can't find any indication what the minor part of the Format: is > > meant to mean, even historically. I thought I remembered it being pretty > > pointless -- ie, if you can unpack X.y, you can unpack X.z for all y, > > z; which means there's not actually any value to having it in the .dsc > > at all. > You don't give your opinion on my precise question. It depends what the Format: field means. You could have it be supersetting, ie "anything Format: x.0 can do, Format: x+1.0 can also do". That's the behaviour I'd expect, personally. But you could also have it be mutually exclusive -- so that taking any format source package, with Format: x.0 and changing it to Format: y.0 (without changing anything else) will always break. Or you could have it somewhere in between, so that it sometimes breaks, and sometimes doesn't. There's two sorts of changes you can make of course -- ones that add new information that couldn't previously be expressed or interpreted (eg, a new file that doesn't match src_ver.tar.gz, srv_upver.orig.tar.gz, src_ver.diff.gz, or a new field like Apply-Patches-From: debian/patches), or ones that change the interpretation of previously valid sources (eg automatically applying patches found in debian/patches as part of unpacking). As best I understand it, taking a regular source package and changing "Format: 1.0" to "Format: 1.5" shouldn't break anything (it should still unpack and work), whereas changing "Format: 1.0" to "Format: 4.0" obviously will. You could just as easily have the Format: field express new interpretation as a minor increase (1.1 -> 1.2), and changed interpretation as a major increase (2.0 -> 3.0). In that case, wignpen might be a major increase because it automatically applies patches, while git/bzr are actually only a minor increase, because they just introduce new functionality that previous dpkg-source's would error out on anyway. > Does it make sense to have a native package (a single .tar) with > debian/patches/ auto-applied at extraction time? That's how the wignpen format's defined, so yes -- though you could arbitrarily restrict that by: - requiring Format: 2.0 to distinguish from old-style native - requiring a different name for the source file (.orig.tar.gz with no .diff.gz) - requiring all wignpen packages to include at least two source files (foo_1.0.orig.*, foo_1.0-1.debian.*) Having each method supply a can_extract just means making sure that you don't have two methods claiming they can extract the same archive (or at least, that they wouldn't end up with different results if they did). > Another question, are there some users of source packages with "Format: 2.0" > and do we need to support such packages currently or can we decide for > example that Format: 2.0 comes with a component in parenthesis too ? I'm not terribly convinced that adding a parenthetical component to the Format: field is a good idea in the first place (and it's easy enough to avoid if you have a file naming convention and a can_unpack function), but if you do introduce it, you definitely should be bumping the Format: number, and 2.* is already claimed... Heh. If the value after the dot really isn't useful, you could also call it "Format: 3.git" etc, without changing the specification of the field, or introducing a new field. :) Cheers, aj
Attachment:
signature.asc
Description: Digital signature