On 09/02/2021 00:39, François Bissey wrote:
It looks like “--no-same-owner” does work in the end.
However, I bumped into a probably subtle bug in portage.
Before the permission were right I had to un-merge the
package (emerge -C …) first, then merge it again.
It looks like the ownership is not changed if there are files
from a previous install. Even if the new install has different
ownership. It could be interesting to see if permission are
affected as well.
I'm pretty sure this behavior is intentional and not a bug. If an user
were to change the permissions/owner of some file to adapt it to his/her
configuration and an update would overwrite this. Well that would lead
to annoying breakage on this users system on every update/rebuild.
If an ebuild for whatever reason has to change the owner/permissions of
an existing file I guess the pkg_postinst/pkg_preinst phases could be used.
On 9/02/2021, at 12:03, François Bissey <frp.bis...@gmail.com> wrote:
Just for the record so that some root cause of the issue are more clear.
From “man tar”
--no-same-owner
Extract files as yourself (default for ordinary users).
--same-owner
Try extracting files with the same ownership as exists in the
archive (default for superuser).
======
So, by default, when you emerge with root, tar will try to preserve ownership
as stated inside the tarball. I was hoping that inserting “—no-same-owner”
in the tar command would changes things a little bit. But for some reasons
it didn’t have any effect when I inserted it inside the makefile.
On 9/02/2021, at 11:55, François Bissey <frp.bis...@gmail.com> wrote:
Nope, just plain emerge as root.
On 9/02/2021, at 11:55, Aisha Tammy <gentoo.scie...@aisha.cc> wrote:
Are you installing/building with the ebuild command and then merging with sudo
or
something similar?
That may be one reason something like this is happening.
On 2/8/21 5:28 PM, François Bissey wrote:
Hi all,
I discovered an issue in a couple of packages for which sage-on-gentoo
provides ebuilds.
Some packages install data directly from a tar command. By that I mean
Makefile.am will a line like
cd $(DESTDIR)$(dbdir) && tar xf $(dist_db_DATA) && rm $(dist_db_DATA)
From a real Makefile at
https://github.com/sagemath/p_group_cohomology/blob/master/present/Makefile.am
I looks innocuous until you realise it has some funny effects on ownership.
fbissey@moonloop ~ $ ll /usr/share/pGroupCohomology/
total 1.1M
drwxr-xr-x 270 root root 12K Feb 3 21:55 .
drwxr-xr-x 319 root root 12K Feb 3 21:55 ..
drwxr-xr-x 3 fbissey fbissey 4.0K Feb 9 10:46 64gp1
drwxr-xr-x 4 fbissey fbissey 4.0K Feb 9 10:46 64gp10
drwxr-xr-x 4 fbissey fbissey 4.0K Feb 9 10:46 64gp100
drwxr-xr-x 4 fbissey fbissey 4.0K Feb 9 10:46 64gp101
drwxr-xr-x 4 fbissey fbissey 4.0K Feb 9 10:46 64gp102
the files in the tarball are owned by user/group 1001:1001
and on my system it is my personal user.
sci-mathematics/singular and that may include the version in the main tree,
would have to check, install its documentation from a tarball as well
fbissey@moonloop ~ $ ll /usr/share/doc/singular-4.1.1_p2-r3/
total 216K
drwxr-xr-x 3 2345 uucp 4.0K Nov 10 10:49 .
drwxr-xr-x 1361 root root 64K Feb 9 10:39 ..
drwxr-xr-x 2 2345 uucp 128K Nov 10 10:49 html
-rw-r--r-- 1 root root 497 Nov 10 10:48 README.bz2
-rw-r--r-- 1 root root 517 Nov 10 10:48 README.md.bz2
-rw-r--r-- 1 root root 585 Nov 10 10:48 README.pkg.bz2
fbissey@moonloop ~ $ ll /usr/share/doc/singular-4.1.1_p2-r3/html
total 30M
drwxr-xr-x 2 2345 uucp 128K Nov 10 10:49 .
drwxr-xr-x 3 2345 uucp 4.0K Nov 10 10:49 ..
-rwxr-xr-x 1 2345 uucp 915 Feb 14 2018 a_begin.gif
-rwxr-xr-x 1 2345 uucp 909 Feb 14 2018 a_begin_na.gif
-rwxr-xr-x 1 2345 uucp 927 Feb 14 2018 a_document.gif
I tried to use fowners inside the ebuild, but it only fixes file ownership,
folders are not touched. I tried to insert “—no-same-owner” in the call to tar
and that didn’t really help either. At best, I am expecting ownership to change
to portage:portage.
Has anyone dealt with something like this before? Apart from “recursively”
scripting install in the make file is there anything simple I could do?
Cheers,
François
