You are not logged in.
i noticed the last two pipewire updates have clobbered pipewire.conf files instead of adding a new pipewire.conf.pacnew file. the latest update today did it again and i had to go back and re-edit pipewire.conf. i can understand pipewire needing new updates to the config, but why not add the new one as a pacnew and report it to the user during the update like normal practice?
Last edited by orlfman (2021-06-10 07:22:09)
Offline
The only pipewire.conf I can find in the package is in /usr/share/pipewire/pipewire.conf
Which as the name /usr/share suggests is not supposed to be edited. For this reason, the PKGBUILD does not declare the file as a backup file, which means pacman considers it an ordinary file and does not try to preserve the contents.
It's a feature that pacman actually does restore the pristine version of regular files like /usr/bin/foobar or /usr/share/foobar/importantresourcefile.txt if you reinstall/upgrade the package. And pacman doesn't rely on stupid, ridiculously ineffective heuristics like "consider every *.conf file to be eligible for pacnew". backup files are an actual metadata field, which packages MUST USE if applicable, and can be any name at all. But by convention not in /usr/share.
Did you try *creating* /etc/pipewire/pipewire.conf instead?
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
The only pipewire.conf I can find in the package is in /usr/share/pipewire/pipewire.conf
Which as the name /usr/share suggests is not supposed to be edited. For this reason, the PKGBUILD does not declare the file as a backup file, which means pacman considers it an ordinary file and does not try to preserve the contents.
It's a feature that pacman actually does restore the pristine version of regular files like /usr/bin/foobar or /usr/share/foobar/importantresourcefile.txt if you reinstall/upgrade the package. And pacman doesn't rely on stupid, ridiculously ineffective heuristics like "consider every *.conf file to be eligible for pacnew". backup files are an actual metadata field, which packages MUST USE if applicable, and can be any name at all. But by convention not in /usr/share.
Did you try *creating* /etc/pipewire/pipewire.conf instead?
hi! pipewire.conf use to be located in /etc but the developer moved it out of /etc to /usr/share/pipewire instead. i don't know if it can still be read by pipewire.conf in /etc but i'll give it a try.
Offline
i don't know if it can still be read by pipewire.conf in /etc but i'll give it a try.
No need to wonder. It's in the man page: https://man.archlinux.org/man/extra/pip … .conf.5.en
Offline
orlfman wrote:i don't know if it can still be read by pipewire.conf in /etc but i'll give it a try.
No need to wonder. It's in the man page: https://man.archlinux.org/man/extra/pip … .conf.5.en
thank you. i went ahead and copied /usr/share/pipewire back to /etc. and reset the /usr/share config back to what is was before i modified it. it does indeed work after moving my config to /etc.
Offline