Actually I should be a bit more precise. Ownership of file was changed without any issues. Ownership of folders was not. So the files are replaced but the folders are not, and that means if you change the ownership of the folders between revisions of the same ebuild (or next version of the package), it is not done without extra action.
It is alright if you get it right the first time. But here it is a bit of an after thought. I have two packages so far that do the tarball unpacking thing that can give funny ownership if you don’t do it right. I suspect there are more out there. > On 9/02/2021, at 21:28, Andrew Ammerlaan <andrewammerl...@riseup.net> wrote: > > 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 >>>>> >>>> >>> >> > >
