[Slackbuilds-users] template idea: --no-same-owner

[Yiannis]

--no-same-owner: yes, this works.
It does exactly what "chown -R root:root ." does, symlinks included.
Both leave every entry root:root, and both leave the symlink's target
outside the tree untouched -- chown -R defaults to -P, so it lchown()s
the link rather than following it. I could not find a case where they
differ. The option predates any Slackware we still support, so its age
isn't a concern.

One place where --no-same-owner is a bug fix, not a simplification ruby/ as
example look here:
https://git.slackbuilds.org/slackbuilds/tree/ruby/rubygem-parallel/rubygem-parallel.SlackBuild?h=15.0&id=608168806da9306799ec6aec884828f38a85e8d4

rubygem-template has no chown/find pass at all, but it does this:
  tar -x -O --file=$CWD/$SRCNAM-$VERSION.gem data.tar.gz \
    | tar -xz -C $PKGDOC --file=- <documentation>

That second tar runs as root with --same-owner in effect, writes
straight into $PKG, and nothing corrects it afterwards. If built a
synthetic gem to check: the doc file landed in $PKGDOC owned by the
upstream packager's uid, and that's what makepkg ships. Adding
--no-same-owner to that second tar fixes it. Worth doing regardless of
what happens to the rest of this.

--no-same-permissions: no! this one doesn't hold up.
umask can only clear bits, never set them, so it can't do the job the
find/chmod block exists for.

The question is, is it worth the effort to change a few thousand
SlackBuilds for no real reason?
 I mean, if it's just to change `chown -R root:root .` with `tar
--no-same-owner -xvf ...`
I would suggest you focus on SBo/ruby/* for that alone.

thanks


Στις Δευ 10 Αυγ 2026 στις 2:44 π.μ., ο/η Christoph Willing <
chris.willing at linux.com> έγραψε:

> On 10/8/26 07:28, B. Watson wrote:
> >
> > So the templates all do this:
> >
> > rm -rf $PRGNAM-$VERSION
> > tar xvf $CWD/$PRGNAM-$VERSION.tar.gz
> > cd $PRGNAM-$VERSION
> > chown -R root:root .
> >
> > ...but looking at the tar man page, there's this:
> >
> >   --no-same-owner
> >          Extract files as yourself (default for ordinary users).
> >
> > ...which would extract the tarball and set the ownership to root:root
> > in one step. I don't know when this option got added to tar, but it
> > seems like using it would simplify things (do the same job in less
> > code).
> >
> > So the template would look something like:
> >
> > rm -rf $PRGNAM-$VERSION
> > tar xvf $CWD/$PRGNAM-$VERSION.tar.gz --no-same-owner
> > cd $PRGNAM-$VERSION
> >
> > There's also this:
> >
> > --no-same-permissions
> >        Apply the user's umask when extracting permissions from the
> > archive (default for or‐
> >        dinary users).
> >
> > ...which might substitute for (or at least simplify) the find/chmod
> > stuff.
> >
> > Thoughts?
>
>
> Good idea.
>
> I tried the --no-same-owner thing on some of the SlackBuilds I use a
> while back and the only reason I didn't persist was the need to update
> them all after each weekly SBo update.
>
> The main reason I was playing with it at all was that, when using a
> docker container for building, tar extraction would sometimes fail
> because files would be extracted to illegal uid or gid. In reality, that
> could have been due to faulty /etc/sub{git,uid} settings but using
> --no-same-owner overcame the problem for me.
>
> chris
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260810/6bdfaae0/attachment-0001.htm>