Hello,
looks like https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Dynamic_allocation sets a precedent that "getent" utility can be taken for granted. Or is "Requires(pre): glibc-common" omitted just by accident?
What about a package that uses getent in an auxiliary script, is it any different? Should there rather be path-based dependency as used with systemd, "Requires: /usr/bin/getent"?
Thanks for guidance.
"JP" == Jan Pokorný jpokorny@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<
On 22/05/18 17:09 -0500, Jason L Tibbitts III wrote:
"JP" == Jan Pokorný jpokorny@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.
"JP" == Jan Pokorný jpokorny@redhat.com writes:
JP> which somewhat complicates the picture :-)
Not really. If someone wants to change the assumptions which underlie such things then fine, this is part of the work they'll need to do. Right now, in Fedora (not something which may be derived from Fedora), scriptlets execute with bash and have glibc available. Packagers are allowed to assume that.
If that situation changes (and, sure, it might as Fedora is going in all different directions these days) then fixing things up is going to be part of the effort to make that change, and everything will be loudly announced well in advance.
Honestly I think that many of these corner cases relating to scriptlets will be significantly simplified by the efforts to simply make scriptlets go away. Witness what we've done with ldconfig, which eliminated a significant source of scriptlet.
- J<
packaging@lists.fedoraproject.org
-
Jan Pokorný -
Jason L Tibbitts III