On 22/05/18 17:09 -0500, Jason L Tibbitts III wrote:
>>>>> "JP" == Jan Pokorný
<jpokorny(a)redhat.com> writes:
JP> Hello, looks like
JP>
https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Dynamic_allocation
JP> sets a precedent that "getent" utility can be taken for granted. Or
JP> is "Requires(pre): glibc-common" omitted just by accident?
Well, in order to run the scriptlet, you have to have the shell to run
it. Which implies that you have glibc. Which implies that you have
glibc-common and thus the getent executable.
Strictly viewed, there's a busybox option (including shell
implementation), say in a container. I mention it just out
of curiousity, as it's unlikely the system delivered rpm
executable itself would ever be linked statically -- huh,
just figured out busybox doubles as "rpm", too:
$ busybox rpm --help
BusyBox v1.28.3 (2018-04-05 14:22:45 UTC) multi-call binary.
Usage: rpm -i PACKAGE.rpm; rpm -qp[ildc] PACKAGE.rpm
Manipulate RPM packages
Commands:
-i Install package
-qp Query package
-qpi Show information
-qpl List contents
-qpd List documents
-qpc List config files
which somewhat complicates the picture :-)
If things were split in such a way that you weren't guaranteed
to
already have getent then, yeah, you would need an explicit dependency
and we would have to fix guidelines and the various packages before that
split landed in rawhide. But I expect that we're going to stop using
scriptlets for user creation before that becomes an issue. (I thought
we might be at that point already, but I guess not.)
Also, if the scriptlet was instead written in lua (%pre -p <lua>) then,
yes, a dependency would be required to guarantee that your %pre script
wasn't run before the C library is installed.
The implications based on the scriptlet handler did not occur to me,
TBH.
JP> What about a package that uses getent in an auxiliary script,
is it
JP> any different?
How is that script going to be run? If it's in a way that somehow
doesn't require the C library, then yes, you will need to guarantee
dependency ordering.
It's going to be run with bash, and the (sub)package contains compiled
executables hence already requires C library implicitly.
So the conclusion I make is that it'd be superfluous to add a new
dependency for getent specifically.
Certainly if you want to be completely, absolutely safe against any
package splits and changes in dependency trees, you can list out
exactly the paths you need as dependencies. It doesn't hurt, but you
may find yourself listing out a large number of things. At some point
it does reach a certain level of absurdity.
I agree it's a trade-off to some extent with any non-trivial package
especially if it carries shell scripts.
With the same package, I've recently added so far missing dependencies
on procps-ng and psmisc packages for a similar reason I was considering
glibc-common but I think that, unlike this one, that's hardly debatable.
All in all, thanks for clarification.
--
Jan (Poki)