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.


> On 9/02/2021, at 12:03, François Bissey <[email protected]> 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 <[email protected]> wrote:
>> 
>> Nope, just plain emerge as root.
>> 
>>> On 9/02/2021, at 11:55, Aisha Tammy <[email protected]> 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
>>> 
>>> 
>> 
>> 
> 
> 


Reply via email to