Github messages for voidlinux
 help / color / mirror / Atom feed
From: ahesford <ahesford@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: base-files: don't overwrite existing locale and define default LANG
Date: Fri, 01 Mar 2024 12:26:53 +0100	[thread overview]
Message-ID: <20240301112653.2EFD528B17@inbox.vuxu.org> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-39264@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/39264#issuecomment-1973016786

Comment:
I think this is getting far too complicated for the simple intent of preserving variables that have already been set. I had to read that loop several times to figure out what it was doing even knowing your intent.

It's also fragile. You're effectively just sourcing the file after wrapping all simple variable assignments in `: ${VAR=value}` to preserve variables already set by the environment while trying to honor existing workflows that might try to inject more complicated behavior into `locale.conf`, but there's no way to guarantee that these kinds of modifications to what's executed during the `eval` won't have all sorts of unintended consequences.

I think there are four reasonable ways to solve your problem (with varying degrees of reasonability):
1. Leave the behavior as is and let users guard variables they might not want to overwrite, knowing that `locale.conf` is executed by the shell.
2. Gate the sourcing like in Arch, which you said people don't like. But do those people who objected really prefer writing trying to implement an even more complex shell parser in the shell itself?
3. Make backup copies of all relevant variables, just source the file as we already do, and restore the backup copies if they were nonempty before the source. I think you did this, in a couple of different ways, in an earlier proposal.
4. Properly validate that `locale.conf` contains nothing more than comments or simple `VAR=value` assignments. Reject it entirely if it does not conform, otherwise parse accordingly.

  parent reply	other threads:[~2024-03-01 11:26 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-13 18:23 [PR PATCH] " oreo639
2022-09-13 18:25 ` [PR PATCH] [Updated] " oreo639
2022-09-26  6:36 ` oreo639
2022-09-26  6:36 ` oreo639
2022-09-26  6:37 ` oreo639
2022-12-26  1:57 ` github-actions
2022-12-26  2:02 ` oreo639
2022-12-26  2:22 ` [PR PATCH] [Updated] " oreo639
2023-01-02 15:29 ` leahneukirchen
2023-01-02 19:53 ` oreo639
2023-01-02 19:54 ` oreo639
2023-01-02 20:23 ` oreo639
2023-01-03  5:45 ` oreo639
2023-01-03  5:45 ` oreo639
2023-01-03  5:45 ` oreo639
2023-04-03  2:41 ` [PR PATCH] [Updated] " oreo639
2023-06-20  3:00 ` oreo639
2023-06-20  3:14 ` [PR REVIEW] " classabbyamp
2023-06-20  3:18 ` [PR PATCH] [Updated] " oreo639
2023-06-20  3:43 ` oreo639
2023-06-20  4:29 ` oreo639
2023-06-20 21:08 ` oreo639
2023-06-20 21:21 ` oreo639
2023-06-21 10:37 ` oreo639
2023-06-21 11:08 ` oreo639
2023-06-21 11:10 ` oreo639
2023-06-21 11:14 ` oreo639
2023-06-21 11:47 ` oreo639
2023-09-20  1:45 ` github-actions
2023-09-20  5:06 ` oreo639
2023-09-21 16:05 ` leahneukirchen
2023-09-21 19:09 ` oreo639
2023-09-21 20:37 ` oreo639
2023-09-21 21:03 ` [PR PATCH] [Updated] " oreo639
2023-09-21 21:06 ` oreo639
2023-09-21 21:10 ` oreo639
2023-09-21 21:11 ` [PR PATCH] [Updated] " oreo639
2023-09-21 21:14 ` oreo639
2023-09-22 20:35 ` ahesford
2023-12-22  1:46 ` github-actions
2023-12-22  2:14 ` oreo639
2023-12-22  2:52 ` ahesford
2023-12-22  3:02 ` oreo639
2023-12-22  3:04 ` oreo639
2023-12-22 11:33 ` ahesford
2023-12-22 11:33 ` ahesford
2023-12-23  8:14 ` oreo639
2023-12-23  8:21 ` oreo639
2023-12-23  8:21 ` oreo639
2024-03-01  2:36 ` [PR PATCH] [Updated] " oreo639
2024-03-01  2:41 ` oreo639
2024-03-01  2:41 ` oreo639
2024-03-01  2:42 ` oreo639
2024-03-01  2:50 ` oreo639
2024-03-01  2:54 ` oreo639
2024-03-01  3:09 ` [PR PATCH] [Updated] " oreo639
2024-03-01  4:01 ` oreo639
2024-03-01  5:26 ` oreo639
2024-03-01  8:14 ` oreo639
2024-03-01 11:26 ` ahesford [this message]
2024-03-01 22:31 ` [PR PATCH] [Updated] " oreo639
2024-03-01 22:31 ` oreo639
2024-03-01 22:33 ` oreo639
2024-03-01 22:54 ` [PR PATCH] [Updated] " oreo639
2024-03-01 22:55 ` oreo639
2024-03-01 22:57 ` oreo639
2024-03-01 23:11 ` [PR PATCH] [Updated] " oreo639
2024-03-01 23:13 ` oreo639
2024-03-02  0:06 ` oreo639
2024-03-02  0:12 ` oreo639
2024-03-02  0:15 ` oreo639
2024-03-04 15:31 ` leahneukirchen
2024-03-04 19:52 ` [PR PATCH] [Updated] " oreo639

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=20240301112653.2EFD528B17@inbox.vuxu.org \
    --to=ahesford@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /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).