From owner-freebsd-doc@freebsd.org Tue Sep 26 06:51:41 2017 Return-Path: Delivered-To: freebsd-doc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2D4BE013DC for ; Tue, 26 Sep 2017 06:51:41 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 691BE7DDD3 for ; Tue, 26 Sep 2017 06:51:40 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (unknown [IPv6:2001:8b0:151:1:1c1d:86a1:a200:b700]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 970549BC7 for ; Tue, 26 Sep 2017 06:51:37 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Subject: Re: Porters Handbook section 4.4 To: freebsd-doc@freebsd.org References: <8a3e663a-d94f-0ef7-bbc7-8ebaa111f6dd@FreeBSD.org> <7b2f2464-5c35-e24a-2047-838c1a9e96a3@FreeBSD.org> From: Matthew Seaman Message-ID: Date: Tue, 26 Sep 2017 07:51:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fG2kubWj6oufnDj84vXbcrjG5T8jX8heT" X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 06:51:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fG2kubWj6oufnDj84vXbcrjG5T8jX8heT Content-Type: multipart/mixed; boundary="tXUCTqKKPwbDatXDkcdMDUSOQmEGJwR3h"; protected-headers="v1" From: Matthew Seaman To: freebsd-doc@freebsd.org Message-ID: Subject: Re: Porters Handbook section 4.4 References: <8a3e663a-d94f-0ef7-bbc7-8ebaa111f6dd@FreeBSD.org> <7b2f2464-5c35-e24a-2047-838c1a9e96a3@FreeBSD.org> In-Reply-To: --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 wro= te: >> On 9/26/17 2:53 PM, Russell Haley wrote: >>> On Sun, Sep 24, 2017 at 10:02 PM, Kubilay Kocak 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 >> % 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/ (WRKSRC) >> ``` >> >> At this point, make the source changes in WRKSRC: >> >> ``` >> % cp .orig >> % edit >> ``` >> >> 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 >> ``` >> >> Finally, run the {{{makepatch}}} target >> >> ``` >> % make makepatch >> ``` >> >> The makepatch target recursively searches WRKSRC for /.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--