Re: Status of new source formats project
On Sun, 02 Aug 2009, Charles Plessy wrote:
> But actually, among the programs that are not distributed upstream in a tar.gz
> format, we in the Debian Med team have as many zip cases as bzip2. Do you think
> that it would be possible to support zip format (i.e. .zip, .jar and .xpi
> extensions) for Debian source packages version 3?
Not really. First of all, that support should have been implemented with
the rest so that it's available in lenny already. Then many options and
features rely on the fact that tar is used. So it would probably requires
addition of a supplementary abstraction/indirection.
> I understand that it would require to change a few things in the Dpkg perl
> modules, as they assume that the original archives are always using tar. I have
> quite poor programming skills, but if you and others do not have time but
> nevertheless are interested by such a modification, I can try to work on a
> patch (possibly using libarchive-any-perl). In that case, can you tell me what
> kind of timeline would fit?
I try to avoid depending on modules outside of perl-modules. I might
consider a patch if it's clean enough but then it will be not easy to
integrate it cleanly.
Then it will also require supplementary modifications to dak to allow .zip
and I don't know if ftpmasters would like it, you should better check this
> Another question that I would like to ask is on the auto-patching
> functionality. One of the programs we package, EMBOSS, is released once a year
> every 15th of July, and other updates are made via patches. Currently it is
> possible to just give the patch to quilt to apply it. With the new source
> format ‘3.0 (quilt)’, it is not possible. Do you think it would be possible to
> change this behavior or at least to disable the auto-patching facilities?
Why would it be impossible? You can modify the patch series to integrate
whatever set of patches that you want...
You can avoid using auto-patching of course, just put your patches
somewhere else than debian/patches/.
> It would be of course easy to convert the patch, but I would really
> prefer to stay as identical to upstream's materials as possible.
How are patches distributed and what kind of conversions is needed?