git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Derrick Stolee <derrickstolee@github.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Đoàn Trần Công Danh" <congdanhqx@gmail.com>,
	"Todd Zullinger" <tmz@pobox.com>,
	"Renato Botelho" <garga@freebsd.org>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: git maintenance broken on FreeBSD
Date: Mon, 15 Aug 2022 09:22:40 -0400	[thread overview]
Message-ID: <1dd29f43-1a8e-eb69-3320-7f5140a0e18e@github.com> (raw)
In-Reply-To: <Yvfg7WwL8oCdxqzQ@tapette.crustytoothpaste.net>

On 8/13/2022 1:35 PM, brian m. carlson wrote:
> On 2022-08-13 at 17:26:05, Junio C Hamano wrote:
>> Does FreeBSD offer choices of cron implementations other than Vixie,
>> just like some Linux distributions?  If somebody on a non-FreeBSD
>> platform happens to choose to use Vixie, then they would presumably
>> have the same problem, so a compile-time switch, whose default is
>> hardcoded based on the target platform, would not work very well.
>> The default will be wrong for some users, and users can later choose
>> to switch between different cron implementations.
> 
> I'm using Debian unstable, and I'm using Vixie cron.  I believe that's
> the default implementation.  However, I could also well use cronie,
> since that's available in Debian as well.  So, yeah, I think this is a
> thing to consider.
> 
>> Configuration knob can be used as a workaround, but in this case, I
>> am not sure if it is worth doing.  What's the downside of securely
>> opening a temporary file and write whatever we are currently piping
>> to a spawned "crontab" command and then giving the path to that
>> temporary file to the "crontab" command?  Wouldn't that give us the
>> maximal portability without that much code, no?
> 
> I think we should try to provide an option which works across at least
> the versions on a particular OS.  The temporary file seems like a nice,
> portable option, so I think we should just do that unless there's some
> practical objection.
> 
> If Derrick doesn't get to it this next week, I can send a patch.

I agree that the tempfile approach makes the most sense in terms of
what we can do within the Git codebase.

I won't be able to get to this change this week, so I'd be happy to
review one of yours, brian. Be careful to test manually when making
this change, because our tests don't actually interact with the system's
crontab and instead verify the interaction using replacement commands.

Thanks,
-Stolee

  reply	other threads:[~2022-08-15 13:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12 13:51 git maintenance broken on FreeBSD Renato Botelho
2022-08-12 14:44 ` Đoàn Trần Công Danh
2022-08-13  3:42   ` Todd Zullinger
2022-08-13  5:02     ` Junio C Hamano
2022-08-13 15:37       ` Đoàn Trần Công Danh
2022-08-13 17:26         ` Junio C Hamano
2022-08-13 17:35           ` brian m. carlson
2022-08-15 13:22             ` Derrick Stolee [this message]
2022-08-15 16:09               ` Junio C Hamano
2022-08-23  1:01               ` [PATCH] gc: use temporary file for editing crontab brian m. carlson
2022-08-23  9:12                 ` Johannes Schindelin
2022-08-23 17:06                   ` Derrick Stolee
2022-08-23 21:15                     ` brian m. carlson
2022-08-24 16:06                       ` Junio C Hamano
2022-08-28 21:41                 ` [PATCH v2] " brian m. carlson
2022-08-29  6:46                   ` Junio C Hamano
2022-08-29 10:52                   ` Renato Botelho
2022-08-30 13:27                   ` Derrick Stolee
2022-08-30 20:40                   ` [PATCH] test-crontab: minor memory and error handling fixes Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1dd29f43-1a8e-eb69-3320-7f5140a0e18e@github.com \
    --to=derrickstolee@github.com \
    --cc=congdanhqx@gmail.com \
    --cc=garga@freebsd.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    --cc=tmz@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).