Re: [sourcev3] Mapping between Format and Dpkg::Source::Package object
Hi,
On Sun, 02 Mar 2008, Anthony Towns wrote:
> On Fri, Feb 29, 2008 at 06:23:03PM +0100, Raphael Hertzog wrote:
> > The logic of the mapping is quite simple, explanation by example:
> > Format: 1.0 => Dpkg::Source::Package::V1_0
> > Format: 3.0 (git) => Dpkg::Source::Package::V3_0::git
>
> > Ideally I'd like each object to implement a single logic of
> > extraction/build of the source package. However "Format: 1.0" contains
> > two logics: native (single tar) and non-native (orig.tar + diff)
> > and it's restrained to gzip compression for everything.
>
> 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).
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.
Each scheme has advantages/drawbacks. I've not yet found a nice approach
with the current code. Maybe reimplementing the support of those options
and having it less intermixed with the "origdiff/native" code would let
me easily plug it where needed.
> > 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.
Does it make sense to have a native package (a single .tar) with
debian/patches/ auto-applied at extraction time? Or can we drop that
from the various use case that we're trying to cater to?
My personal opinion is that it doesn't make sense. And if a derivative
distribution wants to apply patches against the native tarball coming from
Debian, it can easily rename the .tar.gz to .orig.tar.gz and use the
wignpen format as the debian directory in the .orig.tar.gz will be
replaced by the debian directory that they ship.
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 ?
The existence of version 2.0 and version 3.0 at the same time will be
confusing for people and we might prefer to offer only version 2.0 but
with the following variants:
2.0 (native)
2.0 (origdiff)
2.0 (wignpen)
2.0 (quilt)
2.0 (git)
2.0 (bzr)
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: