[arch-general] Upgrading mlocate: /var/lib/mlocate/ Permissions Warning.

[Eli Schwartz]

On 06/10/2018 07:50 AM, Ralph Corderoy wrote:
> And I think that was correct since the package's `Makefile.am' has
> 
>     dbdir = $(localstatedir)/mlocate
>     ...
>     install-exec-local:
>        $(MKDIR_P) "$(DESTDIR)$(dbdir)"
>        -chgrp $(groupname) "$(DESTDIR)$(dbdir)" 2>/dev/null \
>   →            && chmod g=rx,o= "$(DESTDIR)$(dbdir)"
> 
> AFAICS that file hasn't changed between git's upstream/0.26 in the
> Debian repo and mlocate-0.26-14-gc98bf65 in the current one.

I think that's incorrect, because those lines in the Makefile are never run.

There's no group "mlocate" in a clean chroot, so this command errors and
the whole install-exec-local hook gets skipped. Even more fun: some
"genius" decided to send error messages to /dev/null, so it's not even
immediately obvious why it errors, until you patch the Makefile.am and
retry building.

I suggest you report an upstream bug. At the very least this should be a
./configure option so distros can specify a UID/GID instead of some
groupname that might not exist.

...

However, I do not have mlocate installed and I cannot understand why, if
I try building the old mlocate PKGBUILD (after hacking the source array
because anonscm is dead, but they've got tarballs of the repositories; I
don't understand why it ever used that site in the first place)...

I get a built package that contains:

drwxr-xr-x  0 root   root        0 Jun 10 08:22 var/lib/mlocate/

Which is exactly what the current PKGBUILD contains. This is definitely
a bug, since it should be owned by the mlocate group, but the bug is not
the one you think it is.

Please report a bug for the mlocate package. This is wrong and has
always been wrong, and I'm not sure why this is the first time it was
noticed. Did many people fix their directory ownership/permissions by
hand or something, then forget to report a bug? Did you do so too?

>> I assume pacman never touches permissions on existing directories,

Correct, directories are not automatically removed and reinstalled and
users might wish to modify the permissions for many reasons (which is
not typically the case for files).

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20180610/55f4653e/attachment.asc>