[arch-general] Upgrading mlocate: /var/lib/mlocate/ Permissions Warning.
Tinu Weber
takeya at bluewin.ch
Sun Jun 10 13:11:20 UTC 2018
On Sun, Jun 10, 2018 at 12:50:04 +0100, Ralph Corderoy wrote:
> Doesn't PKGBUILD explicitly ensuring `locate' is 750, `mlocate's
> filesystem value, suggest it should do similar for `mlocate' to avoid
> the mismatch?
No idea, but it's possible. Especially because -
> 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)"
What happens if you remove the leading dash from that line? I assume
either `chrgrp` or `chmod` fails at some point...
I tried building mlocate myself, but I run into this error with makepkg:
==> Making package: mlocate 0.26.git.20170220-1 (Sun 10 Jun 2018 15:03:17 CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
==> ERROR: /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is not a clone of https://pagure.io/mlocate.git
Aborting...
Same error with makechrootpkg. I can't find anything weird with the
mlocate PKGBUILD though.
> 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.
It's indeed odd...
> Thus my wondering if the package is faulty for having 755.
Yeah, probably that is not intended.
> If not, then presumably a PKGBUILD function gets added to convert
> existing installations?
I'm sorry, but I don't understand that sentence.
Best,
Tinu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20180610/b81af2f2/attachment.asc>
More information about the arch-general
mailing list