Re: Committer Request - wip/newsraft

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 23.01.2024 um 18:15 schrieb Greg Troxel:
> This seems off.  A buildlink3 results in a full depends, normally, and
> one uses DEPENDS for packages that must be present at runtime but which
> are not used at build time.

The "are not used at build time" may be a little confusing, as a DEPENDS
dependency is indeed installed while building the main package, as well
as at runtime. So whether or not the dependency is "used" by the package
is up to the package itself. The package may inspect the executable or
data files of the dependency, but in cross builds will not be able to
run them.

> It's odd that sqlite3 is DEPENDS but not bl3, but if the program runs
> the sqlite3 binary and does not link to the lib, it is ok.

That's indeed odd. On the one hand, newsraft's README.md file lists
sqlite as a runtime dependency, on the other hand, db-items.c makes use
of the SQLite C API. The problem is that on NetBSD, there is an
sqlite3.h in /usr/include, which gets picked up. So newsraft ends up as
being compiled against the system-provided SQLite3 but then needlessly
depends on a completely unrelated and unused SQLite3 package. On
platforms that don't provide SQLite3, the build will fail.

> As for pax, I know we tend to do that.  I do wonder what others think
> about interaction with INSTALL_* and ending up with the right metadata
> about ownership.

There are lots of other packages that use cp or pax for installing
files, and since pkgsrc doesn't check the binary packages strictly for
ownership of the installed files, that's OK for now.

To detect mismatches in the general case, pkgsrc would need a custom
bulk build where BINOWN, BINGRP, SHAREOWN, etc. are all set to different
usernames. Then we could inspect the binary packages to see how
widespread these permission/ownership problems are in practice.

Roland