From nobody Tue Apr 12 16:36:08 2022 X-Original-To: freebsd-hackers@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 7C60611D8636 for ; Tue, 12 Apr 2022 16:36:11 +0000 (UTC) (envelope-from theraven@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 4KdBDp6FnPz4ddH for ; Tue, 12 Apr 2022 16:36:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649781371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n40rhCO5QfH2KpgJZs1ZFpwqiL6lZqLSE2CRIo/NawQ=; b=BiGCNuKBDNtWZ90HjF/9oNVOS0342+M2wDbXn3+3ezd0M4h+GB3niLaeAYPscMAYpuy7At xjRAoOz9Jeb8GcapHbqH4I1jlW+NEfRQIDp5AKfmpw5uI0Ma5ScuJ80IMvYQGIKrpka2kN IdSQUJIi+0i1dyazWHaukZJPbqYqCpc5Wzz3BsascBjlPcIF7lTHdl45+mrtXwc/8z+lhX vsiFCvEdd07GatMLwpvIbktm15M3pXkmdsI8hbHEX+l1sUjaXg+0TMBAND3H4moSvz99bp rmhU40tzXOdl0cVUP5xbl/4z0WA8PyyljNxqwc/sM3UaJ0o+ng4tBAF20CDNTQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id A892D207B3 for ; Tue, 12 Apr 2022 16:36:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 5F69030517 for ; Tue, 12 Apr 2022 17:36:09 +0100 (BST) Message-ID: <6c8a812f-438c-dfac-7ba8-b9ae6abf0840@FreeBSD.org> Date: Tue, 12 Apr 2022 17:36:08 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC] patch's default backup behavior Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <202204111658.23BGwmcC073621@gndrsh.dnsmgr.net> From: David Chisnall In-Reply-To: <202204111658.23BGwmcC073621@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649781371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n40rhCO5QfH2KpgJZs1ZFpwqiL6lZqLSE2CRIo/NawQ=; b=x6Ov/jgaQQqOFwRTpaxJYqDYaczrz/8I/celnCoDiwCclD0FiqQ6qPPF69/rAJTt8yYj4z uNkJdpILe0FH3emjFEDaMeNr7wQGZbiDukd/bwJncaiWbiNlqUcyPPIGfRuSvauHQBunhK 2rL9QKtirf87lc66H1d0R/h3iU4rqLvp8Wlw/15lPIjWreUteHioqvtFx/iJWpeESIX78l lhd+3l1494/6lEvo7i8yHiXMZWenAyWRGNa/vERUHLONeGabNxG5afZI5CngKwQ+SK2xbz 7fCQEhr0ch+ytuHdk9YMyeNkf/XNhDOqnSSJ4e2UYlf7ITw8tXMvjXUdRKv6Vg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649781371; a=rsa-sha256; cv=none; b=A6gotdeK8uHUrs3szl1mA1A+UJ2wj6Krul7dha+8M287reHz/JhoNS1GmvVxlA25ilJ9Vl XrVIqXT6U25W/80E24eDgSxXOQ2qmTW5sKpat7TPpGquISmI62qCcvLkq3iS2bKwMrvFOF tnsl7BTaaUsdqIIdLSgIpmjgtOI9bi0f6rFJIWyzjjOd0eUAM2VSVI324X/g9mPu7HrqMd FoVglfM6rDaGPdaPi6YnignDM1jIfWPppr6D0YVzhs2TPE1bGCTGPLvGaKtCqWvCAXo6CB 0KRpXia9TcP9TMdsj/dpnlsM4uwJq9RT4wkN5FrszxpQo5fiQ7NiRMXbluDLqA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/04/2022 17:58, Rodney W. Grimes wrote: > Personally, if YOU like the behavior of gnu patch, by all means, > please USE gnu patch. Please do NOT make bsd patch behave in > a different manner simply because you personally like that > other behavior. > > If you want the stuff to look like Linux/GNU by all means, > go RUN linux/gnu!!!! There are two opinions that as almost invariably wrong, in any context: - Popular thing X does Y, therefore Y is good. - Popular thing X does Y, therefore Y is bad. This thread started with 'popular thing X does Y, we do Z, let's evaluate which is better'. Reducing that to 'popular thing X does Y, therefore we should do Z, if you want Y then you should run X' is unhelpful. It is also how we end up in a situation where everyone runs X and we sit around wondering where all of our users and contributors went. We should neither adopt or discard a particular behaviour in patch on the basis that GNU patch does it. We should use the fact that GNU patch does it to gather data on whether it's a desirable behaviour. We should adopt their good ideas and avoid their bad ideas. That is precisely the process that Kyle is trying to drive and the FreeBSD system will be better as a result of his work. Personally, I hate having .rej and .orig files scattered over my filesystem as a result of patch failing and I end up having to write a `find` command to delete them all. Does that mean that I want to give up kqueue, capsicum, out-of-the-box ZFS, a sane /dev/dsp, jails, clang as the system compiler, a `tar` that knows that `x` means 'extract the thing, you don't need me to duplicate the information in the file header to know what it is', and so on and run GNU/Linux? No. I take Joerg's point that GNU patch *sometimes* creating them makes tooling difficult. I would be quite happy with a solution that they are created unconditionally with a flag to disable creating them (I would then `alias patch="patch --do-not-leave-stuff-on-my-filesystem"` in my `.profile` and forget about it for interactive use) or that they are never created with a flag to enable creating them, which I would never pass except when working with bits of infrastructure that explicitly want the .orig files. David