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
>>
>>
>
>
