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