If a user tries to –remove a package that’s listed in HoldPkg, pacman will ask for confirmation before proceeding. Shell-style glob patterns are allowed.
So, no, that option is not to prevent the install of glibc-locales, but rather to prevent the removal.
There’s no way to know Required By value of a package before it gets installed, so let it install, then issue:
That’s interesting…ly weird, as a package normally only lists what it depends on, but not what depends on it, as the latter is potentially externally modified packages from another repository. But I guess it just lists packages on the same repository, no?
On my host machine it was never installed. But on new VM’s and new installs, I’ll have to uninstall because it is in the packages-root and I don’t think I can prevent it ---- unless I use architect??
Removing requires cleanup of the files that were copied to /usr/lib/locale and reinstalling glibc to restore locale-gen (or just modify/copy the script).
I hope it doesn’t get required
Didn’t know about dependency-checker. Cool! I almost always turn to pacman -Sii as my default viewing of a package. It seems to give the most information.
glibc-locales is normally used in our ARM branch. It simply provides all locales of glibc. Since ARM slightly lack to be in-sync with x86_64 we currently have a slight miss-match in the versions. However that normally doesn’t matter as the locales mostly won’t change and are binaries anyway.
So you can remove that package if you want. On the pinephone it is needed to have the gnome-initial-setup find all languages and locales to begin with and you won’t want to compile all the locales on the phone when glibc gets updated. Hence the package.
Doesn’t the below show up in the OP. …
I’m a little bit mad at myself because I know the difference between the two options, but I typed the wrong one. Dang.
In summary: I removed the package and put it in the IgnorePkg list in pacman.conf. I know you said that nothing requires it, as evident from the pacman display, and this is not necessary. I’ll remove it at a future date when I figure out how to incorporate this into our automation.
I don’t understand why you put it in the IgnorePkg list, as mentioned already, it doesn’t prevent you from installing the package, just prevents updating it.
There is no immediate technical reason to do so at this time.
I left it for documentation, educational purposes, and a placeholder for something I need to review. It doesn’t hurt anything and it will catch it if dependencies change.