What should the official ownership and permissions be for the directory /var/tmp/pamac/dbs/sync and files /var/tmp/pamac/dbs/sync/*?
Should /var/tmp/pamac/dbs/sync/* and /var/lib/pacman/sync/* be the same (except for Manjaro specific files like mhwd.db and pamac_aur.db)?
In other words, when pamac command line is executed and I see messages like those below, should those db files be propagated to /var/lib/pacman/sync/ so pamac and pacman are in sync.
If they don’t remain in sync, isn’t it possible that a pamac search and pacman -S could return different results.
The working folder is created on the fly by pamac - so there is no specific permissions.
The dbs/local is a symlink to /var/lib/pacman and that folder is owned by root with read permissions for everyone.
But if you run pamac as root it would likely result in the data being owned by root and perhaps causing issues when pamac is later run as user - trying to update the database.
Yes, that would likely be the case.
I suppose pamac contains logic to keep the databases in sync.
I don’t normally run pamac-tray and other services that automate the mirrors, cache, or repositories. Through some testing on a VM, I figured this much out:
If pamac-tray creates the files the ownership is the desktop user.
If pamac, GUI or CLI, creates the files the ownership is root.
On the ISO the files are owned by the desktop user manjaro.
The files are first created when the user logs on to their desktop, see #1.
If the files are deleted, they will be recreated depending on which runs first , #1 or #2.
I think there is something else going on but this is a start
I use to think that /var/tmp/pamac/dbs/sync and /var/lib/pacman/sync were kept in sync. I mean, it would create problems if there were 2 different versions of the mirrors on your system, but I think that is what is happening and why there are a number of Topics similar to the one below.
There are 2 updating utilities, pamac and pacman (not even going to touch octopi and others), each with their own view of the sync databases. This is exacerbated by the pamac-tray application refreshing on the RefreshPeriod.
It seems if a user wants to make sure that the pamac sync databases and pacman’s sync databases are in sync, the following needs to be executed:
Tested the above. All I can say at this time is I’ve been getting the same results. I don’t understand pamac’s and pamac-tray’s relationship between /var/tmp/pamac/dbs/sync and /var/lib/pacman/sync.
I think one thing that definitely should be consistent is the ownership and permissions. As mentioned above if pamac-tray creates sync, the owner is the desktop user. If pamac creates sync, the owner is root. So now if pamac-tray runs, the user gets “cp: cannot create regular file … Permission denied”. I was running pamac-tray from a terminal in the foreground, the normal user won’t know this has failed, unless they look at ~/.xsession-errors (not sure where in wayland).
Script to compare pacman and pamac sync databases
!/bin/bash
#===============================================================================
#
# Description
#
# Compare pamac and pacman sync databases during tests which include
# `pamac update` as root, user, and with sudoer and polkit customization.
#
#===============================================================================
set -u
declare controlDir='/var/lib/pacman/sync'
declare compareDir='/var/tmp/pamac/dbs/sync'
date
read -rep '? Update pacman *.files [y|N]: '
if [[ "${REPLY:-n}" == [yY] ]]; then
sudo pacman -Fy
fi
echo
read -rep '? pamac version [y|N]: '
if [[ "${REPLY:-n}" == [yY] ]]; then
pamac list -i | grep pamac | sed -r 's/\s+/ /g'
fi
echo
declare -- compareFile='' resultText=''
printf -- '= Compare sha256sum between %s/* and %s/*\n' "${controlDir}" "${compareDir}"
while read -re checksum controlFile; do
compareFile="${compareDir}"'/'"${controlFile##*/}"
if [[ ! -e "${compareFile}" ]]; then
resultText='Missing'
elif [[ "${checksum}" != $( sha256sum "${compareFile}" 2>/dev/null | cut -d' ' -f1 ) ]]; then
resultText='Not Equal'
else
resultText='Equal'
fi
printf -- '%10s: %s\n' "${resultText}" "${compareFile}"
resultText=''
done < <( sha256sum "${controlDir}"'/'* )
echo
echo "= stat -c '%A %U %G %s %.16y %n' ${controlDir} ${controlDir}/* | column -t -R 4"
stat -c '%A %U %G %s %.16y %n' "${controlDir}" "${controlDir}"'/'* | column -t -R 4
echo
echo "= stat -c '%A %U %G %s %.16y %n' ${compareDir} ${compareDir}/* | column -t -R 4"
stat -c '%A %U %G %s %.16y %n' "${compareDir}" "${compareDir}"'/'* | column -t -R 4
Why would they need to be in sync at all? Updating system means sync+update anyway… unless of course you do something stupid like…
And last time I checked (been more than a year probably), you could select wheter you want pamac to use libalpm or pacman directly. So (my guess) switching to pacman will “fix” your databases problem.
I use pacman, and only use pamac for the AUR (vs yay). I do know others that use only pamac. All testing is on a VM. I test pamac because it is Manjaro’s tool. I have experienced the same issue others have (cp… permission denied) and was trying to understand and then help But it wasn’t as quick and easy as I thought, starting with pamac-tray and pamac file creation permissions.
I could reason either way, but how is it intended to work. In general, if they are not in sync, then a user needs to be aware that pamac and pacman could produce different results at a minimum.
If dbpath is /var/lib/pacman and tmp_dbpath is /var/tmp/pamac/dbs and I see the snippet below in libpamac-master/src/alpm_config.vala, the data is being copied if it doesn’t exist and pacman is current. This would save resources.
If the problem is users running pamac with sudo then instead of telling them not to (which is useless apparently) why not adding a simple if EUID==0 statement?
There is a checkupdates script if you want to check for updates. And if you want to check for updates in pamac…well I don’t know what they use. But my point is, if it doesn’t work in pamac, then someone should probably fix pamac. It has nothing to do with dbs being in sync.
It has nothing to do with dbs being in sync.