<div dir="ltr"><div dir="ltr"><div>--no-same-owner: yes, this works.</div><div>It does exactly what "chown -R root:root ." does, symlinks included.<br>Both leave every entry root:root, and both leave the symlink's target<br>outside the tree untouched -- chown -R defaults to -P, so it lchown()s<br>the link rather than following it. I could not find a case where they<br>differ. The option predates any Slackware we still support, so its age<br>isn't a concern.<br><br></div>One place where --no-same-owner is a bug fix, not a simplification ruby/ as example look here: <a href="https://git.slackbuilds.org/slackbuilds/tree/ruby/rubygem-parallel/rubygem-parallel.SlackBuild?h=15.0&id=608168806da9306799ec6aec884828f38a85e8d4">https://git.slackbuilds.org/slackbuilds/tree/ruby/rubygem-parallel/rubygem-parallel.SlackBuild?h=15.0&id=608168806da9306799ec6aec884828f38a85e8d4</a><br><br>rubygem-template has no chown/find pass at all, but it does this:<br>  tar -x -O --file=$CWD/$SRCNAM-$VERSION.gem data.tar.gz \<br>    | tar -xz -C $PKGDOC --file=- <documentation><br><br>That second tar runs as root with --same-owner in effect, writes<br>straight into $PKG, and nothing corrects it afterwards. If built a<br>synthetic gem to check: the doc file landed in $PKGDOC owned by the<br>upstream packager's uid, and that's what makepkg ships. Adding<br>--no-same-owner to that second tar fixes it. Worth doing regardless of<br>what happens to the rest of this.<br><br>--no-same-permissions: no! this one doesn't hold up.<br>umask can only clear bits, never set them, so it can't do the job the<br>find/chmod block exists for.<br><br>The question is, is it worth the effort to change a few thousand SlackBuilds for no real reason?</div><div dir="ltr"> I mean, if it's just to change `chown -R root:root .` with `tar --no-same-owner -xvf ...`<br>I would suggest you focus on SBo/ruby/* for that alone.<br><br></div><div>thanks</div><div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Στις Δευ 10 Αυγ 2026 στις 2:44 π.μ., ο/η Christoph Willing <<a href="mailto:chris.willing@linux.com">chris.willing@linux.com</a>> έγραψε:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/8/26 07:28, B. Watson wrote:<br>
><br>
> So the templates all do this:<br>
><br>
> rm -rf $PRGNAM-$VERSION<br>
> tar xvf $CWD/$PRGNAM-$VERSION.tar.gz<br>
> cd $PRGNAM-$VERSION<br>
> chown -R root:root .<br>
><br>
> ...but looking at the tar man page, there's this:<br>
><br>
>   --no-same-owner<br>
>          Extract files as yourself (default for ordinary users).<br>
><br>
> ...which would extract the tarball and set the ownership to root:root<br>
> in one step. I don't know when this option got added to tar, but it<br>
> seems like using it would simplify things (do the same job in less<br>
> code).<br>
><br>
> So the template would look something like:<br>
><br>
> rm -rf $PRGNAM-$VERSION<br>
> tar xvf $CWD/$PRGNAM-$VERSION.tar.gz --no-same-owner<br>
> cd $PRGNAM-$VERSION<br>
><br>
> There's also this:<br>
><br>
> --no-same-permissions<br>
>        Apply the user's umask when extracting permissions from the <br>
> archive (default for or‐<br>
>        dinary users).<br>
><br>
> ...which might substitute for (or at least simplify) the find/chmod <br>
> stuff.<br>
><br>
> Thoughts?<br>
<br>
<br>
Good idea.<br>
<br>
I tried the --no-same-owner thing on some of the SlackBuilds I use a <br>
while back and the only reason I didn't persist was the need to update <br>
them all after each weekly SBo update.<br>
<br>
The main reason I was playing with it at all was that, when using a <br>
docker container for building, tar extraction would sometimes fail <br>
because files would be extracted to illegal uid or gid. In reality, that <br>
could have been due to faulty /etc/sub{git,uid} settings but using <br>
--no-same-owner overcame the problem for me.<br>
<br>
chris<br>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
</blockquote></div></div>