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

[Yiannis]

sbopkglint is fine -- it complains exactly as it should. I built
rubygem-ast (orphaned, no deps, unmodified doc pipeline) and linted it:

  Running test: 10-docs...
  --- ERR: bad ownership (should be root:root) in doc dir:
  -rw-r--r-- 1 root wheel 1089 Jan 23  2021
usr/doc/rubygem-ast-2.4.2/LICENSE.MIT
  -rw-r--r-- 1 root wheel  482 Jan 23  2021 usr/doc/rubygem-ast-2.4.2/
README.YARD.md
  FAILED

So a new rubygem submission written to the current template fails the
lint we tell submitters to run. That's the whole of the problem.

I need to correct my own explanation, though: it's not the packager's
uid, it's the group, and it's hardcoded. Every entry in a gem is
recorded with the *name* wheel:

  $ tar -x -O --file=ast-2.4.2.gem data.tar.gz | tar -tvz
  -rw-r--r-- wheel/wheel    1089 2021-01-23 20:56 LICENSE.MIT
  -rw-r--r-- wheel/wheel     482 2021-01-23 20:56 README.YARD.md
  -rw-r--r-- wheel/wheel     586 2021-01-23 20:56 lib/ast.rb
  [...]

RubyGems' tar_header.rb defaults uname and gname to "wheel" and never
sets uid/gid, so gems carry uid 0 / gid 0 / uname wheel / gname wheel.
GNU tar as root resolves the names before the numbers unless you give it
--numeric-owner. There's no wheel user, so uid falls back to 0 -> root.
There is a wheel group -> root:wheel.

What makes it unambiguous is that the gem records wheel/wheel for
*every* file, including lib/*.rb -- but those come out root:root in the
package, because gem install writes them itself. Only the files that go
through tar are affected. Same build, same source archive:

  drwxr-xr-x root/root   usr/doc/rubygem-ast-2.4.2/
  -rw-r--r-- root/wheel  usr/doc/rubygem-ast-2.4.2/LICENSE.MIT
  -rw-r--r-- root/wheel  usr/doc/rubygem-ast-2.4.2/README.YARD.md
  -rw-r--r-- root/root   usr/doc/rubygem-ast-2.4.2/rubygem-ast.SlackBuild

The SlackBuild in that same directory is root:root because it's written
with cat. 2 offending entries out of 73.

rubygem-template is the only template with no "chown -R root:root ."
anywhere, and that second tar is the one place in it where ownership is
restored from an archive rather than created by the process doing the
writing. --no-same-owner (or --numeric-owner) on that line fixes it.

ps. I used a translation tool and hope everything is ok now :)

Στις Δευ 10 Αυγ 2026 στις 12:37 μ.μ., ο/η B. Watson <urchlay at slackware.uk>
έγραψε:

>
>
> 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._______________________________________________
> 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/20260811/bbf78995/attachment.htm>