From owner-freebsd-ports@FreeBSD.ORG Tue Dec 21 15:42:21 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 317AA106566B for ; Tue, 21 Dec 2010 15:42:21 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C03FC8FC0A for ; Tue, 21 Dec 2010 15:42:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date; bh=y2uhSlthT1UcgsnHCHFUXOqBqWQDCyoYCxq/UFJiy3Y=; b=ltNofPpc6GtXD8HQxg/TJUZe0tRAlEt6oEI2AT7C/ZRnQuyEvL5NnD5VwB/ungt1vCFUvkLe6JZe+C0t+2mwpC25yufoEXlh/TopF6w76SwwD3uRYk5mzpabNcSj4MeMsMy5NpJdtQvsBIKnuHJcTB1Om/68j2x1pKJa7HiiKmiUaNgMhzLkMP9MFRf5QU7s+iEFr/9+5C4/SyidFjstYopWWNCrxibbkYlosR6AXpbRyihRn8gCSgVAaVSrMKCGfbTeHWW5qcd1XQX/dHZU4ane4hs8v4GvmmhmZXSA3zhz9E/7hjEb2jTK79im0V2Egr4wXGgDMis5bT6fD0Gbgw==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1PV4Am-000HJh-Jb; Tue, 21 Dec 2010 18:30:44 +0300 Date: Tue, 21 Dec 2010 18:30:42 +0300 From: Eygene Ryabinkin To: freebsd-ports@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sender: rea@codelabs.ru Cc: Olli Hauer Subject: RFC: 'make makepatch' and alternatives X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 15:42:21 -0000 Greetings! I had a dispute with Olli Hauer about the usage of the 'makepatch' target for generating port patchfiles. I am currently using patchfiles for my ports that are generated by the version control systems and are grouped by-commit. But there is an old, good makepatch target that creates per-file diffs based on all applied patches. Section 4.4 of Porters Handbook says that there should be no two patch files that modify the single source file, so, in general, my approach is a kind of herecy. As I understand, there are just two sound reasons to use the makepatch: - one has no need to worry about the patch order: hunks are grouped by-file, so any patch order will go; - one can simply invoke 'make makepatch' to produce all patchfiles automatically after the virgin sources were patched and .orig files were left in place. There is the third reason from the Porters Handbook: "To make fixes and upgrades easier, you should avoid having more than one patch fix the same file", but frankly, I don't quite understand its meaning, apart =66rom the reasoning in the point 1 raised above. =46rom the other hand, by-commit patchfiles have the good property that they carry the vital metadata: the grouping of hunks and, in some cases, the comments about the patch itself (Git patches are good example of this). And, if the author of the patch makes a reasonable effort to make single commits to be grouped by-topic (rather than squelching multiple unrelated or loosely related modifications into a single commit), such metadata is rather useful both for maintainer and persons who will add/modify port patches. Here are my reasons: - suppose, one is upgrading the port from version X to version Y and he finds that the patch A doesn't apply; the most common reasons for this are a) upstream sources were changed in some non-trivial way, but there is still a need to patch, but the original one should be modified for the new version; b) the patch was taken upstream (perhaps, with some modifications, but there is no need to modify the original patch, since the original problem was fixed, but, may be, in the different way); In either case, by-commit grouping will permit the porter to immediately identify the hunks that should be either thrown out or modified; with the by-file approach, one will need to identify all hunks in different patchfiles that are related to the said modification; - suppose, the non-maintainer has to create new patch for the port because he want to fix some problem, upgrade the port or for some other reason; he looks into the files/ directory and sees a bunch of patch files with a bunch of hunks inside each, but he can't easily track their interrelations -- a time should be spent to figure out what hunks serve what purpose. By-commit patchfiles have no such problem -- the metadata is already here. Olli said to me that by-file grouping makes it easier to understand what files were patched. That's true, but it is not so hard to get this information from the by-commit patchfiles: it is a trivial scripting that can be added to the bsd.port.mk (I can provide it if it is really needed). And, transforming the by-commit patches into by-file is a loss of data in a strict mathematical sense: transformation by-commit -> by-file has no single inverse function, there are multiple variants how by-file hunks can be regrouped into by-commit ones. There is a slight problem with the by-commit patches: their order can matter, but if _PATCHFILES inside bsd.port.mk will be sorted alphabetically, then a simple naming like 'patch-NNNN[abcd]-whatever' will be sufficient: suppose there are already patches {{{ patch-0001-fix-one patch-0002-fix-two patch-0003-fix-three }}} and we want to insert another patch between 2nd and 3rd. The name like "patch-0002a-fix-two-prime" will do the trick. I am obviously not trying to force anyone to move to the by-commit patchfiles, but I just want to know - if I am missing something with the generally-adopted scheme with "make makepatch" - if it seems reasonable to other people to employ the by-commit patch grouping. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]