Date: Tue, 26 Sep 2017 07:51:30 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-doc@freebsd.org Subject: Re: Porters Handbook section 4.4 Message-ID: <c06acce6-edd7-fab5-2419-e441f1064128@FreeBSD.org> In-Reply-To: <CABx9NuTUmeSU8yYkiYpR2vGYkhTV_MiHuNJYqZvLwJ9Q97B8Zg@mail.gmail.com> References: <CABx9NuSC=tVieJ=dk6%2BFucvfEfNGHCRMuHcy%2BNxo9QW%2BtS8-gA@mail.gmail.com> <8a3e663a-d94f-0ef7-bbc7-8ebaa111f6dd@FreeBSD.org> <CABx9NuS6ie6fVwMh68wpRmRE6MsuGDfKQgLdVVZaeL_HJrKVOg@mail.gmail.com> <7b2f2464-5c35-e24a-2047-838c1a9e96a3@FreeBSD.org> <CABx9NuTUmeSU8yYkiYpR2vGYkhTV_MiHuNJYqZvLwJ9Q97B8Zg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fG2kubWj6oufnDj84vXbcrjG5T8jX8heT
Content-Type: multipart/mixed; boundary="tXUCTqKKPwbDatXDkcdMDUSOQmEGJwR3h";
protected-headers="v1"
From: Matthew Seaman <matthew@FreeBSD.org>
To: freebsd-doc@freebsd.org
Message-ID: <c06acce6-edd7-fab5-2419-e441f1064128@FreeBSD.org>
Subject: Re: Porters Handbook section 4.4
References: <CABx9NuSC=tVieJ=dk6+FucvfEfNGHCRMuHcy+Nxo9QW+tS8-gA@mail.gmail.com>
<8a3e663a-d94f-0ef7-bbc7-8ebaa111f6dd@FreeBSD.org>
<CABx9NuS6ie6fVwMh68wpRmRE6MsuGDfKQgLdVVZaeL_HJrKVOg@mail.gmail.com>
<7b2f2464-5c35-e24a-2047-838c1a9e96a3@FreeBSD.org>
<CABx9NuTUmeSU8yYkiYpR2vGYkhTV_MiHuNJYqZvLwJ9Q97B8Zg@mail.gmail.com>
In-Reply-To: <CABx9NuTUmeSU8yYkiYpR2vGYkhTV_MiHuNJYqZvLwJ9Q97B8Zg@mail.gmail.com>
--tXUCTqKKPwbDatXDkcdMDUSOQmEGJwR3h
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable
On 26/09/2017 07:38, Russell Haley wrote:
> On Mon, Sep 25, 2017 at 11:21 PM, Kubilay Kocak <koobs@freebsd.org> wro=
te:
>> On 9/26/17 2:53 PM, Russell Haley wrote:
>>> On Sun, Sep 24, 2017 at 10:02 PM, Kubilay Kocak <koobs@freebsd.org> w=
rote:
>>>> On 9/25/17 2:08 PM, Russell Haley wrote:
>>>>> Hi,
>>>>>
>>>>> Section 4.3 of the porters handbook talks about making modification=
s
>>>>> to a private copy of a tarball and recording the steps.
>>>>>
>>>>> Section 4.4 talks about changing directories into the affected port=
s
>>>>> dir and running make makepatch to generate patch files.
>>>>>
>>>>> I am unsure how the makepatch target is supposed to find my private=
>>>>> directory. Since I was confused, I created patches, added them to t=
he
>>>>> port, ran make, then ran make makepatch and the system re-generated=
>>>>> new "makepatch" patches.
>>>>
>>>> Quite a number of new users have raised the same question on IRC.
>>>>
>>>>> So, my question is thus:
>>>>>
>>>>> To me, section 4.4 seems vague about where changes should be made,
>>>>> which is compounded by the information in section 4.3. Can the
>>>>> makepatch target ask for and find a private directory, or should th=
e
>>>>> handbook be clarified to state that the changes should be made to t=
he
>>>>> 'work' folder? If the later is true, I assume there is some proper
>>>>> workflow to keep changes from being destroyed while testing?
>>>>
>>>> The handbook section needs to be updated to be less ambiguous with
>>>> regard to where things should be done.
>>>>
>>>> I'd be happy to provide a docs committer with verbiage if they can h=
elp
>>>> with formatting/commit.
>>> Hi,
>>>
>>> If you provide the verbiage, I'll attempt a patch. :)
>>>
>>> Russ
>>>
>>>>> If there is a section in the handbook clarifying this, please just =
say
>>>>> so and I will go find it.
>>>>>
>>>>> Thanks!
>>>>> Russ
>>>>
>>>> ./koobs
>>
>> In section:
>>
>> 4.4. Patching
>>
>> - Add new section (at/numbered 4.4.2)
>> - Name: Automatic Patch Generation
>> - Renumber sections (4.4.2 -> 4.4.3)
>>
>> Text:
>>
>> The ports framework provides a {{{makepatch}} target, which when run,
>> automatically creates correctly named and formatted patch files in the=
>> correct location. The general process is as follows:
>>
>> % cd <port directory>
>> % make patch
>>
>> Note: In the general case, {{{make patch}} is used (not just {{{make
>> extract}}} to extract the DISTFILES), because ports that contain
>> existing patches need to have the patches applied so that they are als=
o
>> generated (regenerated) in the last step.
>>
>> ```
>> % cd work/<directory> (WRKSRC)
>> ```
>>
>> At this point, make the source changes in WRKSRC:
>>
>> ```
>> % cp <file> <file>.orig
>> % edit <file>
>> ```
>>
>> Repeat the above steps for each file at any location within WRKSRC tha=
t
>> needs a patch file created.
>>
>> Go back to the main port directory:
>>
>> ```
>> % cd <port directory>
>> ```
>>
>> Finally, run the {{{makepatch}}} target
>>
>> ```
>> % make makepatch
>> ```
>>
>> The makepatch target recursively searches WRKSRC for <file>/<file>.ori=
g
>> pairs within WRKSRC, and creates a patch file in PATCHDIR from each pa=
ir
>> (using diff).
>>
>> NOTE: Any pre-existing patches in PATCHDIR that are *not* regenerated
>> during the above process are placed in a backup location in WRKDIR. Th=
is
>> backup location is deleted on {{{make clean}}}. This may occur when no=
t
>> using {{{make patch}}} to extract the sources, because existing patche=
s
>> are or were not applied, or if there are existing patch files that mak=
e
>> edits to multiple files in a single patch file, which will now be in
>> separate patch files after makepatch regeneration. Inspect and review
>> the patch files in PATCHDIR to ensure they have been created as expect=
ed.
>>
>> =3D=3D Other =3D=3D
>>
>> - Patch files are stored in PATCHDIR, usually files/, from where they
>> will be automatically applied
>> + Patch files are stored in PATCHDIR, by default `files/` in the port
>> directory, which are automatically applied in the 'patch' stage
>=20
> Thanks! I'll play with this on the weekend.
Could you add some cautionary notes about the impact of using 'make
makepatch' alongside the technique of using replaceable tokens like
%%PREFIX%% with a sed command in the post-patch: target? 'make
makepatch' applied blindly will tend to expand all the replaceable
tokens in the generated patch files. It's something that's quite easy
to do unintentionally.
Cheers,
Matthew
--tXUCTqKKPwbDatXDkcdMDUSOQmEGJwR3h--
--fG2kubWj6oufnDj84vXbcrjG5T8jX8heT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJZyfj5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC
QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATu+gP/3ztP6WUd4En3NKTWBjlWemK
SkaUC7khQTA0B40Vb81NUeWzoXKC/HrKA84ahAZUwGxIgCikemXix8y8wIICK9wG
fPZATwsstzHXHCAI5nr0lyRDDRanQ4TVBSx/5QL4e7hkxtjE2llTNrdWkdyX0g4S
FLjxSumicz6JhXG3KmHPKGmY1C2+GyeNJy88o7LMi+ZS4KPXGRXosSlh1GC5A85q
WR4pLfvFOrqLU31/IE0lPIK6lDB2K1P9QhPTJi9aidfs2ljo0jxxI+p2EdV2gOQB
uTEoyrlA4W/IwJrZ4M9lxk//4a3hDwLuvvqtUTh6dkXgPAq7p/sIhFHT3rcs4kve
PmzUUsnwV4FSva99RkDwuvXjgYi0z00md6s/CWGZgbS2dzVUWg++HYNmFKYzyOzS
3B1XCAygnGRWpyrA565uWAXQRqFccI+56xEyMJ7vZ9Uy42knEGAQD7WaEb9O+JEO
m9wqSO4XbZICaKv/llcn+4QnndzxNz1xYb5BULK6X0Gg7L18ksCTyHzi331P25Nb
Iuo171HUovmWDc1nVI4zSJQbzNsziZgmzWHXuGwhmowddu3rU9TrFnVR1aWSvMtG
D8bzi5f4PdzYd1Rqbj/Y4H4D/prIi+8vpEWqRIMEYukCphmZMi+EeO1nY0T3yeXX
Z2cRZUFfUy+aRk155Q8P
=X2lT
-----END PGP SIGNATURE-----
--fG2kubWj6oufnDj84vXbcrjG5T8jX8heT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c06acce6-edd7-fab5-2419-e441f1064128>