Question about getent/glibc-common in Requires

[Jan Pokorný]

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.

-- 
Jan (Poki)

[Jason L Tibbitts III]

> >>>> "JP" == Jan Pokorný
> <jpokorny(a)redhat.com&gt; 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<

[Jan Pokorný]

On 22/05/18 17:09 -0500, Jason L Tibbitts III wrote:
> >>>>> "JP" == Jan Pokorný
> <jpokorny(a)redhat.com&gt; 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)

[Jason L Tibbitts III]

> >>>> "JP" == Jan Pokorný
> <jpokorny(a)redhat.com&gt; 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<