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