On 29-08-2022 14:57, Thompson, David wrote:
> I disagree. I believe we shouldn't let perfect be the enemy of the good.
I don't think your patch counts as "good" here -- while fixing the bug
counts as "good", you are at the same time introducing a new bug (the
non-atomicity), which is bad. You would have to weigh the goodness and
the badness to end up with an overall "good" (or maybe "bad", depending
on the conclusion), but I'd think that the time required to do such a
weighing is better spent by doing a tiny bit of extra effort to
implement the new field (it should be very low effort, see other response).
My patch has a very limited scope of only changing the gitolite service. Your proposal has a much greater scope of modifying a core structure used for system configuration. The new bug you mention is only bad in a theoretical sense. In practice, the permission bits are misconfigured for a blip of time during system reconfiguration, which is a lot better than being misconfigured all the time which is the status quo. It's the difference between a gitolite that works nicely with cgit/gitweb and one that doesn't. I agree that it's a good goal to improve atomicity and I think making <user-account> more general to allow for different permission bits on the home directory is a good idea, but I see it as one step removed from fixing this particular bug. My patch follows the recommended approach outlined in a comment in (gnu build activation) written by Ludovic in 2019:
;; Always set ownership and permissions for home directories of system
;; accounts. If a service needs looser permissions on its home
;; directories, it can always chmod it in an activation snippet.
- Dave