[sourcev3] Mapping between Format and Dpkg::Source::Package object
Hello,
in the sourcev3 branch I implemented a logical mapping between the
Format: field of the source package and the name of the object
that is able to build/extract the corresponding type of
source package.
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
In dpkg-source, at extraction time, I read the format and I create
the right object and call its extract method. At build time, currently
we always use the V1_0 object. However I plan to have a stack of
build formats to try. For each format, it would call its can_build()
method to decide if it's going to use that format to build the source
package.
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.
We need another object to handle native packages with any compression.
I'm thinking of creating something like "Format: 1.0 (native)" (thus
Dpkg::Source::Package::V1_0::native). For backward compatibility,
DSP::V1_0->extract() would detect a native package and delegate()
to DSP::V1_0::native. Likewise DSP::V1_0::native->build() would put
"Format: 1.0" if the compression used is gzip.
Then by default the stack of formats to try would contain (DSP::V1_0,
DSP::V1_0::native) and the user could push other format on top of the
stack (dpkg-source --format "3.0 (git)" ...). The can_build() method of
V3_0::git would check for example if there's a .git in the directory.
I'd be satisfied with that but I'm wondering if we have to handle
native packages in Format: 2.0 too ... ie have a single .tar.gz
and still have patches in debian/patches auto-applied. Are there
valid use cases for this? Because that would mean that I'd should also
duplicate the same kinds of hack described above in DSP::V2_0 and I'm not
too fond of that idea.
Some quick feedback on that design would be welcome as I plan to work
on this ASAP (this evening/tomorrow).
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: