From nobody Sun Apr 10 15:21:56 2022 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C58781A802A7; Sun, 10 Apr 2022 15:22:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbwhK5BS1z3QT4; Sun, 10 Apr 2022 15:22:09 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649604129; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=f8pnRzvxMYr7mzzuQKb4VNfO3I5D8B4RHQLdO7cAkpM=; b=R5Sgs0XhsfCx0GvjnwTg1SdbMhmywjLHvkpICEV20ucNf83iVE3z3xBHkfssyA0XzBInZL OvsXwm/3Z4hVBVZ0+Pfbh2gtqqxJS1IPPTaQLHYDa40udZIPv9k5Oo5Bl4EdkR1k4nAhHz PSWC27x4ageQQb2Ua98+6LmmatrV54TRnF/+E8ggDpJ6C+icqb//NnV3MgZr4I7i4MZB4g pljnkX6+fU97GWv8KIkVyARv4GXD33MvgNeXdVV9ztioZtjL37uuuNZIB5e7rMVoyPcaj8 T326cns0wfKZdvyJHPbYjT3dbyTSaWdicaft27M2rUZQk4uv3sDqVTt0OW0KSQ== Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 8FE752603F; Sun, 10 Apr 2022 15:22:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f42.google.com with SMTP id bq30so9835971lfb.3; Sun, 10 Apr 2022 08:22:09 -0700 (PDT) X-Gm-Message-State: AOAM533Ft514UNoMPEsNd1csw0SrEcVfnZ8IkSFR9kCTUMh3203nwMzd HYb9saHyUsGpSB6y2FlrxNmdnuO8x1Z08tRQOk8= X-Google-Smtp-Source: ABdhPJw81RkuwjIjEIuoMmfhAKxD0q7To/wBNmepcGP3hCF+WRSVMHLhs8DXScueQpptsVxofzop81HXCAJybeW8Xc0= X-Received: by 2002:a05:6512:39c8:b0:46b:9aed:389f with SMTP id k8-20020a05651239c800b0046b9aed389fmr3816778lfu.194.1649604128153; Sun, 10 Apr 2022 08:22:08 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> In-Reply-To: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> From: Kyle Evans Date: Sun, 10 Apr 2022 10:21:56 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: Matthias Andree Cc: freebsd-arch@freebsd.org, FreeBSD Hackers , ports-list freebsd Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649604129; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=f8pnRzvxMYr7mzzuQKb4VNfO3I5D8B4RHQLdO7cAkpM=; b=Pr68PfcZLqPB1/jcjGpnbodHtWaQqwoyuthlz5gAdq1qZw/gHhVUgZDlLhXmwEHMVI+pOP Mn1VObhmX+cY1KP6iMHEe+0q4sWRDufbsZWu/ceIIpKDq3t2IAuQbNiWXqLzynHrxlJAlG ZIPB5nm3ClncuY7FkKV6FNgJw+HDmY8lSf0QKQ187G6CwWJiu3iOlkP5rHzrI3RSyFR/Ox U97iidGP+QQ0VgK1dQ34MnfxaKXEnRgClPrReVxZCLsqd5QOXMhnoWYIZm40LxSBA1Aon7 EorUTp0CvyjS7OFHv+JLbvtHhtxyr31T+TIdMikbk0BFdP5NfU3vfiRYL39kvQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649604129; a=rsa-sha256; cv=none; b=AWS1qjVBCB1kU6FoW5rQdajzUBmPx83lH3aFdAFFCN4CPv2kWnZ6GpP7NK1VQnQvP3usJZ JMI0TJH5fsgtPep4pQqb0vR5m5FJsovCXGGEOnMT09zG351Vm+ROHHHNLkDxEYbyt+ZAfN tVpAMBIfmpLQJhKAdxBuCIZy7l5o9iWYFs9x7ooyWP4q3vHF8PUxA0Jxuc5Y/MNMybP+oq zqv09W5H72IjWO9AqiB0c44vSp+mHfyRi3xSDVwCOTljjoi/g4VOXlX4LRgtbs26GmkOWX e0YZh8k6n/Wjylil+H4ldsyKQhtlQ4U2TZJiXsoICEu8CQRaap9M/dluIA/CrA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree wrote: > > [resending from hopefully subscribed address that it makes it to some of > the lists] > > Am 09.04.22 um 05:25 schrieb Kyle Evans: > > Hello! > > > > FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > > where a backup is created for every file patched. > > > > I'd like to test the waters on switching this to the GNU behavior, > > which feels a whole lot more reasonable. Notably, they'll only create > > backup files if a mismatch was detected (presumably this means either > > a hunk needed fuzz or a hunk outright failed). This yields far fewer > > backup files in the ideal scenario (context entirely matches), while > > still leaving backup files when it's sensible (base file changed and > > we might want to regenerate the patch). > > > > Thoughts / comments / concerns? Cross-posted this to a couple of > > different lists to try and hit the largest number of stakeholders in > > patch(1) behavior. > > > > Thanks, > > > > Kyle Evans > > > > Kyle, > > you would discard the original reference for gendiff or "make makepatch" > in ports, that would make patch - edit - regenerate-patch cycles require > extra efforts, and if that extra effort is only remembering patch's -b > option, but if we do it consistently for FreeBSD 14 and announce it in > due time beforehand, fine. Certainly worthy of release notes. > Arguably, `make patch` should be using the `-b` option even today to be portable across different patch implementations. Yes, we have our own patch with our own behavior that we can rely on, but I'm personally a fan of not tying ourselves and, perhaps more importantly, others (downstreams) into one behavior when we can trivially wire it down. > I personally also dislike and advise against "magic" and if-then > behavior. It makes documentation less concise, it makes tool behavior > more complex to judge, and from people who script a test-based approach, > this bears potential for confusion, astonishment and other effects, > because behavior as to when we get .orig files gets *apparently* > inconsistent, and may send people who have not read the entire manual to > the letter on detours finding out why they sometimes get .orig, or > worse, when developing patches, and interaction with other tools might > surprise people, too. > There are certainly trade-offs -- with the GNU behavior, you can instead quickly use the presence of an .orig file to know that you may need to sanity check the result and tooling can key off the same rather than checking patch(1) output for words like 'fuzz'. fuzz has bitten people before, it will bite people again. I'm not so sure that the scenario you write about will really happen. GNU patch has done this for many years, and I haven't seen such a proliferation of confusion. If anything, I see more confusion in practice from BSD patch's default differing from both the much more common GNU behavior and also from POSIX-specified behavior. > IF we are to change policy, my vote is to ALWAYS leave the .orig files > away and not only write them if we also write .rej files. I explicitly > dislike the GNU behavior, which seems geared for interactive use rather > than scripting. > re: interactive use, I think that's an entirely separate debate, even. :-) My personal opinion is that defaults *should* be geared more for interactive use, and scripts should be (+ able to be) entirely explicit about the behavior they want. This is a general opinion, not just with patch. If you solidify script usage with flags, then we can be a bit more fluid so that tooling can adapt to the ever-changing user landscape. Obviously you can't reliably predict potential for future behavior changes, though there are some obvious candidates like this one where the difference in defaults between us and other implementations are well-known. > I checked POSIX 2018, apparently the backup files (.orig) are only > required if -b is given, so omitting them would seem fine to me, and the > rationale section suggests that for consistency with other utilities, > the default would be to NOT save .orig file, but the -b option can be > used to request them being written (but then consistently on all files > not just those without rejects - also because there is no working patch > -R for ed-style diffs.). I'd actually be OK with that, too, to an extent. Thanks, Kyle Evans