Trying to find the correct place to raise this issue, today on the Testing branch my system stopped automatically updating because the package mintstick was trying to install its dependency exfatprogs while manjaro shipped with exfat-utils and these packages cause a package conflict.
This means that update scripts using pacman with the --no-confirm option now break their update sequence and I’d like to bring some awareness to this so it can get properly resolved.
exfatprogs is a newer drop-in replacement for exfat-utils but right now because of the conflict the upgrade is not seamless and requires user interaction. So ideally somewhere a change is done that allows exfat-utils to be a substitute for exfatprogs to avoid package conflicts or it will have to be swapped out automatically (full system upgrade?) if we want to avoid this from happening on the stable branch.
If this is not the right place to raise this concern regarding a manjaro provided package update please point me to the right direction, since my forum account is new I have limited posting rights.
To state something you may not be aware of exfat-utils wont work with gparted.
Only exfatprogs works.
not sure if it’s possible but one solution would be to change exfat-utils to exfatprogs in the root packages?
2 Likes
Just did, thanks for the reminder.
1 Like
Good to know that part of it is resolved, can we also get an automatic upgrade path for the existing users so they do not have to manually approve a dependency conflict when installing or updating applications that need exfatprogs?
Automatic updates are neither supported nor recommended.
2 Likes
I will clarify since i am not familiar with the correct terminology for this part of the updater.
Sometimes during updates you get the question if a package should be replaced with a different package to migrate.
For example it will say :
:: Starting full system upgrade…
:: Replace cdra with core/wireless-regdb? [Y/n]
Is this possible for the exfat-utils to exfatprogs upgrade to migrate the existing users over in a similar fashion? Less experienced users may not understand they can safely replace the package and opt for the N default. By presenting them with the replacement the same way as it was done for cdra all users can benefit from the newer exfatprogs package and dependency conflicts would be avoided.
No, as exfatprogs neither conflicts with nor replaces exfat-utils (yet?).