How to fetch and extract patches in archives?

Zero King l2dy at macports.org
Sun Mar 18 12:22:29 UTC 2018


On Sun, Mar 18, 2018 at 12:48:59PM +0100, Rainer Müller wrote:
>On 2018-03-18 12:28, Zero King wrote:
>> On Sun, Mar 18, 2018 at 09:57:58AM +0100, Mojca Miklavec wrote:
>>> On 18 March 2018 at 08:33, Zero King wrote:
>>> I would add the patches to distfiles and include debian site in
>>> master_sites. You then need to keep your fingers crossed that the main
>>> distfile is also packaged as tar.xz because you need to manually
>>> extract some of the files otherwise (MacPorts does not yet support
>>> extracting from different types of archives).
>>
>> The main distfile is tar.gz.
>
>The debian tarball already contains the full sources. Is there a reason
>to use the upstream distfile? If w3m upstream at sf.net is dead, just
>switch to the Debian version that still receives patches.

No, it only contains debian-specific stuff:

drwxr-xr-x  0 0      0           0 Jan 25 09:53 debian/
-rw-r--r--  0 0      0         459 Jan 25 09:49 debian/README.Debian
-rw-r--r--  0 0      0       70430 Jan 25 09:53 debian/changelog
[...]
drwxr-xr-x  0 0      0           0 Jan 25 09:45 debian/patches/
-rw-r--r--  0 0      0        5732 Jan 25 09:37 debian/patches/010_upstream.patch
-rw-r--r--  0 0      0      805357 Jan 25 09:38 debian/patches/020_debian.patch
-rw-r--r--  0 0      0          36 Jan 25 09:45 debian/patches/series

>MacPorts will always try to download files listed in patchfiles from
>patch_sites or master_sites if they are not already in the files/
>directory next to the Portfile. For this, all entries in patchfiles are
>expected to be simple filenames, not full paths. Therefore Mojca's
>suggestion will not work.
>
>
>Solution 1: Download the patches using patch_sites from an URL
>
>Keep the upstream distfile, download additional patches from Debian.
>
>dist_subdir	${name}/${version}
>patchfiles      020_debian.patch
>patch_sites     https://.../debian/patches/
>
>The dist_subdir option is required as these patches are likely to change
>with each version. Of course you could also leave it out at first and
>only add it once it is required.
>
>The downside is that we are relying on sources.debian.org [1], the
>Debian Gitlab [2] or the GitHub mirror [3] serving these files.
>
>[1] https://sources.debian.org/src/w3m/0.5.3-36/debian/patches/
>[2] https://salsa.debian.org/debian/w3m/tree/debian-stretch/debian/patches
>[3] https://github.com/tats/w3m

Thanks for [1] and [2], I didn't know they exist. [3]'s debian/* tags
should work with your solutions below.

What is the downside of relying on them? Plus we have distfile mirroring
now.

>Solution 2: A hack to avoid fetching patchfiles
>
>Only the tarball from Debian is used, no additional downloads.
>
>distfiles          w3m_0.5.3-36.debian.tar.xz
>master_sites       debian:w/w3m
>
>The following pre-patch phase should trick MacPorts into not fetching
>patches by setting the patchfiles option late, but apply them in the
>patch phase:
>
>pre-patch {
>    patchfiles ${worksrcpath}/debian/patches/020_debian.patch
>}
>
>
>Solution 3: A custom post-patch phase to apply these patches
>
>Same as in solution 2, but instead of using the hack, the patches are
>applied manually in a custom post-patch phase. This is probably the most
>flexible solution.
>
>post-patch {
>    foreach p 020_debian.patch ... {
>        system -W ${worksrcpath} "patch -p0 debian/patches/${p}"
>    }
>}

So we have several solutions:

1. keep patches in the ports tree. (not ideal, upstream is dead)
2. fetch debian/* from github.com/tats/w3m and use a hack for patches.
3. use patch_sites sources.debian.org/... salsa.debian.org/...

Any suggestions?

-- 
Best regards,
Zero King
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3612 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20180318/5a029e7c/attachment.bin>


More information about the macports-dev mailing list