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

[B. Watson]

On Mon, 10 Aug 2026, Yiannis wrote:

> --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.

Thanks for this analysis.

> 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.

Interesting. So we have a bunch of ruby/ packages that fail
sbopkglint? It really should complain about those... bug or just an
oversight, maybe.

> --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.

Right. I looked into it and found the same thing.

> 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 ...`

No, I'm not talking about changing every existing script.

I'm talking about changing the template. New builds will be
based on the new template, but we're not going to change existing
(working!) builds just to update to the new template. You're right,
it wouldn't be worth the effort.

If this becomes the new template, we'll encourage maintainers to make
this change in their scripts, when they're already in the process of
updating them (e.g. a version update, editing the script anyway, might
as well align it with the latest template), but we won't *require* it.

> I would suggest you focus on SBo/ruby/* for that alone.

I'll have a look.