Ticket #3682 (closed task: fixed)
Drop automatic migration of configuration from ~/.mc to XDG-base
| Reported by: | andrew_b | Owned by: | andrew_b |
|---|---|---|---|
| Priority: | minor | Milestone: | 4.8.27 |
| Component: | mc-core | Version: | master |
| Keywords: | Cc: | zaytsev | |
| Blocked By: | Blocking: | ||
| Branch state: | merged | Votes for changeset: | committed-master |
Description
Before 4.8.1, the mc configuration was locate in ~/.mc directory. After implementation of XGD-based configuration, mc copies configuration from old directory to new XDG-based place if it doesn't exist and then uses it.
Now after 4 years we can drop this automatic migration and clean up the codebase.
Change History
comment:2 Changed 8 years ago by mooffie
Just to clarify:
There are two migration mechanisms:
- Moving files from ~/.mc to XDG place (done by the old_filename field in the mc_config_files_reference table).
- Moving certain files from one XDG place to another XDG place (done by the mc_config_migrate_rules_fix table). E.g., from ~/.cache/mc/history to ~/.local/share/mc/history. This was needed to fix mistakes we make in choosing the placement of various files.
You're talking about removing only (1), right? Because we're still going to need (2), to fix issues like #3687 (in the future we might want to relocate other files similarly).
In (2) it's probably fine to remove the current rules, though. These rules were added in Nov 2011 (commit 25c9267ac), less than a year after XDG support was added (Dec 2010, commit acbe04848).
comment:3 Changed 8 years ago by mooffie
Some food for thought:
It's possible to compile MC without XDG support. Maybe we should keep the migration code so it could be used (in the future) to migrate these users to XDG?
Feel free to discard this quick note: I haven't thought much about it.
comment:4 Changed 8 years ago by zaytsev
- Cc zaytsev added
I'd say that dropping it now is very premature: RHEL 6 is shipping mc-4.7.0.2 by default (EOL: 2020) and RHEL 5 (EOL: 2017 / 2020) is shipping mc-4.6.1a. I'm not sure what's the situation with SLES, but I bet the situation is similar. I'm not necessarily saying that we have to wait at least 4 more years, but maybe at very least until RHEL 8 comes out. There are still tons and tons of homes to be upgraded...
comment:8 Changed 4 years ago by andrew_b
- Owner set to andrew_b
- Status changed from new to accepted
- Branch state changed from no branch to on review
- Milestone changed from Future Releases to 4.8.27
Branch: 3682_drop_automatic_config_migration
changeset:0b317ea5f265596db8d4387e613aa76ff0d63007
comment:9 Changed 4 years ago by andrew_b
- Votes for changeset set to andrew_b
- Branch state changed from on review to approved
comment:10 Changed 4 years ago by andrew_b
- Status changed from accepted to testing
- Votes for changeset changed from andrew_b to committed-master
- Resolution set to fixed
- Branch state changed from approved to merged
Merged to master: [b6de6e8f2dd170fc104461e1bdefc5a8c6f43958].
