Replies: 3 comments 5 replies
-
Yeah, there's an expectation that all directory attributes match across all packages, otherwise I think this is a bug in the package.
That may or may not be a pacman bug... in any case,
I think pressing |
Beta Was this translation helpful? Give feedback.
-
d'oh! i thought 'd' meant default (apply) :)
are you referring to -Qk or -Dk ? |
Beta Was this translation helpful? Give feedback.
-
i chmodded /etc/bluetooth to 555 (we'll see how that goes), and kept the /usr/bin rules which presumably works around a broken package.
|
Beta Was this translation helpful? Give feedback.
-
recently, my "aconfmgr save" has resulted in this in the output:
this didn't used to be the case, and i certainly didn't mess with permissions or ownership of these paths.
running
pacman -Qo /usr/bin
shows all the packages that put anything in /usr/bin (741 packages!). as for bluetooth:for bluetooth, it seems both these packages default to 555 now. see:
https://gitlab.archlinux.org/archlinux/packaging/packages/bluez/-/blob/main/PKGBUILD#L65
For /usr/bin, my guess is that one of these packages started setting (wrong) new owner/permissions, there might even be disagreement amongst the packages.
Interestingly, `pacman -Syu' does not seem to update ownership/permissions to match the new packages, such that aconfgr doesn't spot a difference?
When I remove the directives and run "aconfmgr apply --paranoid", i see this:
It would be nice if aconfgr mentioned the diff here (package x says it should be y, but per your config it should be z) (adding
-v
does not show more)Beta Was this translation helpful? Give feedback.
All reactions