Bug 1215538

All of the broken packages have a dependency on sysuser-shadow which tries to execute this command only if systemd is installed.

systemd has absolutely no business bein installed inside WSL (or any container). I could uninstall it if it weren't pulled in as a dependency of `man` which I use.

Assigning this to the man maintainers.

(In reply to Bruno Pitrus from comment #1)
> All of the broken packages have a dependency on sysuser-shadow which tries
> to execute this command only if systemd is installed.
> 
> systemd has absolutely no business bein installed inside WSL (or any
> container). I could uninstall it if it weren't pulled in as a dependency of
> `man` which I use.
> 
> Assigning this to the man maintainers.

Why man maintainers?  This is more a systemd problem ... the message

  Failed to take /etc/passwd lock: Invalid argument

shows that some bigger problem.

Because the dependency of `man` on `systemd` is unnecessary.

(In reply to Bruno Pitrus from comment #3)
> Because the dependency of `man` on `systemd` is unnecessary.

You mean that I should ignore that now man or better its mandb command will not be executed without systemd timer?

 rpm -qf /usr/lib/systemd/system/timers.target
 systemd-254.5-5.1.x86_64

 rpm -ql man | grep usr/lib/systemd/system
 /usr/lib/systemd/system/man-db-create.service
 /usr/lib/systemd/system/man-db.service
 /usr/lib/systemd/system/man-db.timer

(In reply to Dr. Werner Fink from comment #4)
> (In reply to Bruno Pitrus from comment #3)
> > Because the dependency of `man` on `systemd` is unnecessary.
> 
> You mean that I should ignore that now man or better its mandb command will
> not be executed without systemd timer?

On WSL and in containers mandb will never be executed by systemd timer, even with your Requires. Because systemd does not run in this environments, even if you add it as Requires.
On a "standard" installation, systemd is always installed and running, we don't support anything else.

(In reply to Thorsten Kukuk from comment #5)
> (In reply to Dr. Werner Fink from comment #4)
> > (In reply to Bruno Pitrus from comment #3)
> > > Because the dependency of `man` on `systemd` is unnecessary.
> > 
> > You mean that I should ignore that now man or better its mandb command will
> > not be executed without systemd timer?
> 
> On WSL and in containers mandb will never be executed by systemd timer, even
> with your Requires. Because systemd does not run in this environments, even
> if you add it as Requires.
> On a "standard" installation, systemd is always installed and running, we
> don't support anything else.

The problem is that running mandb in %post or %posttrans to create man data base  takes ages therefore I use due several bug reports now systemd API.

Are there possibilities to detect in %post or %posttrans during installation time what surrounding environment will be used (WSL, container, or systemd based).

(In reply to Dr. Werner Fink from comment #6)

> Are there possibilities to detect in %post or %posttrans during installation
> time what surrounding environment will be used (WSL, container, or systemd
> based).

I cannot say anything about WSL, but for container: no. This is like building disk images, you know the build environment, but not the final environment.
But for this cases (especially container), it is the responsibility of the person who builds the image to do that, not the one of the package maintainer. He cannot do anything except to make it worse by blowing up pre/post install scripts with more most of the time useless code.

Main problems are: Creation of system group/user man
                   Creation of /var/cache/man
                   Creation of the various index.db below /var/cache/man/
currently done with systemd.

I really want to know why one like to use man in a container ...
now I've readded the old why of adding group/user man if not already done
by systemd also creating /var/cache/man if not done by systemd as well as use filetriggers lua scriptlets to get the index.db below /var/cache/man/ created as well as uptodate

This is an autogenerated message for OBS integration:
This bug (1215538) was mentioned in
https://build.opensuse.org/request/show/1141710 Factory / man

The useradd/groupadd is useless, if there is no systemd installed the fallback is even more clever and supports tools like busybox

For the user creation part I think we should better enhance the sysuser-tools script to use the fallbacks in the case systemd fails, too.
Will try to look at it after my sick leave.

(In reply to Thorsten Kukuk from comment #11)
> For the user creation part I think we should better enhance the
> sysuser-tools script to use the fallbacks in the case systemd fails, too.
> Will try to look at it after my sick leave.

Isn't that what /usr/sbin/sysusers2shadow does in case of missing
/usr/bin/systemd-sysusers? Nevertheless 

The creation of /var/cache/man by systemd-tmpfiles is also a problem if
/usr/bin/systemd-tmpfiles
does not exists

(In reply to Dr. Werner Fink from comment #12)
> (In reply to Thorsten Kukuk from comment #11)
> > For the user creation part I think we should better enhance the
> > sysuser-tools script to use the fallbacks in the case systemd fails, too.
> > Will try to look at it after my sick leave.
> 
> Isn't that what /usr/sbin/sysusers2shadow does in case of missing
> /usr/bin/systemd-sysusers?

If it is missing, yes. If it is failing like in this case, no.

systemd appeared again on my WSL this time through DNF's dependency on python3-systemd.

python3-systemd likewise has no business requiring the systemd daemon (which is UNUSABLE on WSL), only libsystemd0. Reassigning to python-systemd's maintainer.

Debian and Fedora seem to do this correctly btw.