The topic described future problems of the project renaming without intervention into package content file names and paths used to store files on a user PC where the package will be installed.
The news of renaming:
The package owns next
❯ pacman -Ql manjaro-mirrors | grep 'pacman-' manjaro-mirrors /etc/pacman-mirrors.conf manjaro-mirrors /usr/bin/pacman-mirrors manjaro-mirrors /usr/share/libalpm/hooks/pacman-mirrors-install.hook manjaro-mirrors /usr/share/libalpm/hooks/pacman-mirrors-upgrade.hook manjaro-mirrors /usr/share/libalpm/scripts/pacman-mirrors-install manjaro-mirrors /usr/share/libalpm/scripts/pacman-mirrors-upgrade manjaro-mirrors /usr/share/man/man8/pacman-mirrors.8.gz manjaro-mirrors /usr/share/pacman-mirrors/ manjaro-mirrors /usr/share/pacman-mirrors/mirrors.json
If application name is now
manjaro-mirrors, then it would be misleading to store it’s files (bins, configs, assets) by
Why package content should also get renaming after package rename:
Current state of paths and file naming is against the rule of proper (representative / self-described) package files.
Moreover if somebody (now, after a month or a brand new app will appear in any (years) future) will install other package of
pacman-mirrors, it could introduce files rewrites because the only owner of proper bin file name and path to store files in for the
pacman-mirrors is the abstract
pacman-mirrors package by naming convention, not any other package.
To store files the
manjaro-mirrors by path and by names of
pacman-mirrors is and idea to mislead users about package name of the files owner and it is the base to introduce future file conflict by overwriting files of another package with potential/possible name of
Let’s try prevent this issue postponed into future and to get rid of easy-to-be-predicted future conflicts.
Yes, we should rename it’s call in all apps into current proper name, but we know that it will be the only right way to prevent lacks and bugs in future.
Algorithm could go like this:
manjaro-mirrorspackage renames all filenames and paths from
manjaro-mirrorspackage introduces a link files named as old files in
pacman-mirrorshad and they leads to files by new renamed to
manjaro-mirrorsships new version. It works flawlessly for all external software cause now links of old names leads to new filenames and paths of
manjaro-mirrorsinforms all involved software’s authors (which uses
pacman-mirrors) to fix names and paths of binary/configs/assets to call to.
- After informing all involved software’s authors, the transition period starts. I predict it will continue at least to several months.
- After all software, which wants to call
pacman-mirrorsfunctionality got renamed that calls into new names of
manjaro-mirrorspaths and bins, the fallback links to
pacman-mirrorspaths get removed. The
manjaro-mirrorsships the final version without links of transition from one naming to a new one.
And only 6th step frees old naming of
pacman-mirrors to be ready to use to potential
pacman-mirrors package. And cause of that latency the faster we will start the paths transition the cleaner error-free future we will get.
If we can, please let’s do rename properly / fully - according to all naming convention schemes.
At least thank you for your attention, team and forum members!