On 22/05/18 17:09 -0500, Jason L Tibbitts III wrote: >>>>>> "JP" == Jan Pokorný <jpokorny@xxxxxxxxxx> 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)
Attachment:
pgpnN8ns6NdJ9.pgp
Description: PGP signature
_______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx/message/KCFM4M7AYXHZPPY2VEJ7MBJKMSE2QIG4/
