[Discussion] Potential footgun by allowing Distrobox applications to write to host XDG_DATA_ and XDG_CONFIG_HOME directories by default, especially with apps that install into $HOME

Distrobox allows running arbitrary distributions on containers and run their apps seamlessly with the host. The default behavior is to use the host's $HOME in containers. This is usually fine. But there's several issues with this approach which can lead to subtle unpredictable behavior in some edge cases.

- The unpredictability can arise from different package versions between host and container reading and writing to user config, causing unpredictable behavior and failures.

- Some applications are installed under the local user, and one may want to use Distrobox to segment them and avoid cluttering host's .local, and still have access to their .bashrc and ssh keys, or w/e. But by using --home, the seamless integration is not so seamless anymore.

I'm sure we'd like to keep $HOME set to host $HOME, but for apps to keep to their own container as probably intended. There's no middle ground between using --home and not using --home. This can be achieved by leveraging the XDG environment variables.

The solution given to me was to just use --env to pass them directly. This is tedious. I instead proposed a flag to automate this and fill in that middle ground. Any solution should not disrupt the prevailing use case of Distrobox but should nevertheless at least guarantee (to the best of its abilities) a clean configuration environment if needed, while still integrating with the host.

After an unreasonably heated discussion in the Matrix chat, I want to at least open discussion about this problem a little more publicly.

了解 Distrobox 如何設定容器環境，尤其是對 $HOME 和 XDG 環境變數的處理方式。程式碼庫主要由 shell script 組成。首先檢查進入點 script 和容器初始化邏輯，以了解目前的整合方式。目標是設計一個 flag 或機制，讓應用程式能夠寫入容器本地的 XDG 目錄，同時仍然共用主機的 $HOME，以便使用 .bashrc 和 SSH 金鑰等內容。查看現有的關於使用 --home 和 --env 的 issue 或討論，以了解其中的取捨。

由索引模型根據 Issue 內容生成。