Re: [gentoo-science] tip for installing files from tarballs

[François Bissey]

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 <andrewammerlaan@××××××.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.bissey@×××××.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.bissey@×××××.com> wrote:
>>>>
>>>> Nope, just plain emerge as root.
>>>>
>>>>> On 9/02/2021, at 11:55, Aisha Tammy <gentoo.science@×××××.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
>>>>>
>>>>
>>>
>>
>
>