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-mirrors-path-contained files
❯ 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 pacman-mirrors paths.
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 pacman-mirrors.
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 frompacman-mirrorstomanjaro-mirrors. -
manjaro-mirrorspackage introduces a link files named as old files inpacman-mirrorshad and they leads to files by new renamed tomanjaro-mirrorspaths. -
manjaro-mirrorsships new version. It works flawlessly for all external software cause now links of old names leads to new filenames and paths ofmanjaro-mirrors. -
manjaro-mirrorsinforms all involved software’s authors (which usespacman-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 ofmanjaro-mirrorspaths and bins, the fallback links topacman-mirrorspaths get removed. Themanjaro-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!
