Getting prompted about `Restoring a52dec file /usr/bin...` about aconfmgr HOT 14 CLOSED

Is that behavior expected?

Yes.

Ideally I'd also be able to specify the mode explicitly even if it's the same as the default to avoid depending on the package for this.

The default is 644 for files and 755 for directories, and does not depend on the package. But, you're right that this distinction between the default and '' doesn't need to exist.

from aconfmgr.

This is generally caused by different packages packaging the same directory with different permissions.

The information that is currently made available to aconfmgr is only that there exists a package which contains a filesystem entry which doesn't match the current filesystem.

I think the best solution here is to find which package contains the non-conformant file attribute, and contact the packager and ask them to fix this in the packaging script. aconfmgr will probably propose restoring attributes from different sets of packages on every run, depending on what's on the filesystem. Some causes could be an unusual umask or install arguments.

from aconfmgr.

Thanks a lot for the swift response. Sorry for my ignorance, but how do I check which attributes are set for a package? I'm not very familiar with Arch packaging, and looking at the Arch Build System wiki page I didn't find an answer.

from aconfmgr.

Essentially look at the attributes of the directory inside the .pkg.tar.zstd file. You should find that different packages (the ones aconfmgr is complaining about) have that directory in the archive with different attributes.

from aconfmgr.

Thanks @CyberShadow and sorry for my delayed response.
Is it possible to use my aconfmgr config to avoid these prompts?
I will look into contacting the package author, but ideally I would have a way to ignore these issues without waiting for them to fix it (or maintain local modifications to a package).

from aconfmgr.

Is it possible to use my aconfmgr config to avoid these prompts?

Assuming I understand the problem correctly, IgnorePath /usr/lib should work for that purpose. (Though, it also causes lost files to be ignored under that directory...)

from aconfmgr.

Essentially look at the attributes of the directory inside the .pkg.tar.zstd file. You should find that different packages (the ones aconfmgr is complaining about) have that directory in the archive with different attributes.

So I tried that and I don't see a difference between a52dec and other packages. Reproducible docker command to show the issue:

docker run --rm -i --entrypoint=bash archlinux <<'EOF'
  pacman -Sy > /dev/null
  mkdir -p /pkgs && cd /pkgs
  for pkg in a52dec pkgfile; do
    pacman -S --downloadonly --noconfirm "${pkg}" > /dev/null
    mkdir -p "${pkg}"
    zstd -d /var/cache/pacman/pkg/"${pkg}"-*.pkg.tar.zst --stdout | tar --extract --directory "${pkg}"
    ls -ld "${pkg}"/usr/bin
    stat -c '%n: uid %u, gid %g, perms %a' "${pkg}"/usr/bin/
  done
EOF

Output:

drwxr-xr-x 2 root root 4096 May 14  2020 a52dec/usr/bin
a52dec/usr/bin/: uid 0, gid 0, perms 755
drwxr-xr-x 2 root root 4096 May 27  2020 pkgfile/usr/bin
pkgfile/usr/bin/: uid 0, gid 0, perms 755

from aconfmgr.

OK, do you have a way to reproduce the issue you're seeing with aconfmgr?

One thing you could do is watch the permissions of /usr/bin on your filesystem as you let aconfmgr do its repeated attempts to restore of it, and see which steps changes it away from 755.

from aconfmgr.

I'll try to reproduce the issue in a container but I'm currently not even able to reproduce it on my machine /:
I think you can keep this issue closed until I come up with repro steps.

BTW, I also see some issues with files that aconfmgr detects as having the wrong mode, although the mode is correct. For example, I get this for /etc/locale.conf. When I use aconfmgr save it adds a line like SetFileProperty /etc/locale.conf mode ''.
Let me know if you prefer I open a separate issue about that.

from aconfmgr.

And another issue I get is with the nut package. It specifies that config files in /etc/nut should have user root and mode 640 (reference) but aconfmgr things the default is actually 644. I get these messages:

::::: Clearing the following file properties:
:::::: Setting mode of /etc/nut/upsd.users to 644 (default value)
:::::: Setting mode of /etc/nut/upsmon.conf to 644 (default value)
:::::: Setting group of /etc/nut/upsd.conf to root (default value)
:::::: Setting group of /etc/nut/upsmon.conf to root (default value)
:::::: Setting group of /etc/nut/upsd.users to root (default value)
:::::: Setting mode of /etc/nut/upsd.conf to 644 (default value)

from aconfmgr.

SetFileProperty /etc/locale.conf mode ''.

This can be caused by explicitly specifying the default mode (644) in your configuration. Remove that and this will go away. (It's trying to revert the explicit mode to the default mode.)

And another issue I get is with the nut package. It specifies that config files in /etc/nut should have user root and mode 640 (reference) but aconfmgr things the default is actually 644. I get these messages:

I would classify this as a package bug, it should not have files packaged with one mode but declared via tmpfiles to have another mode.

from aconfmgr.

Thanks for all the help!

SetFileProperty /etc/locale.conf mode ''.

This can be caused by explicitly specifying the default mode (644) in your configuration. Remove that and this will go away. (It's trying to revert the explicit mode to the default mode.)

I'll try that now and give an update shortly.

And another issue I get is with the nut package. It specifies that config files in /etc/nut should have user root and mode 640 (reference) but aconfmgr things the default is actually 644. I get these messages:

I would classify this as a package bug, it should not have files packaged with one mode but declared via tmpfiles to have another mode.

My current workaround is to set these attributes explicitly in my aconfmgr config (i.e. SetFileProperty /etc/nut/upsd.conf group nut). Do you think this is reasonable or am I shooting myself in the foot?

from aconfmgr.

Yes, it's reasonable.

from aconfmgr.

SetFileProperty /etc/locale.conf mode ''.

This can be caused by explicitly specifying the default mode (644) in your configuration. Remove that and this will go away. (It's trying to revert the explicit mode to the default mode.)

I'll try that now and give an update shortly.

Your suggestion worked indeed. However I also notice it happens for new files I create with CreateFile (i.e. files that don't belong to any package).
Is that behavior expected?
Ideally I'd also be able to specify the mode explicitly even if it's the same as the default to avoid depending on the package for this.

from aconfmgr.