With rpm 4.18rc1 we've noticed that dnf seems to hang when installing a package
containing a fifo. The hang is from the new openat() call within fsmOpenat()
which dnf is calling from librpm.
Changing the condition in rpmPackageFilesInstall() from:
if (!rc && fd == -1 && !S_ISLNK(fp->sb.st_mode))
The Yocto Project doesn't mandate any particular userspace layout. You can
configure it to match FHS but we expect software to match the configuration
that is set. The issue here is that rpm doesn't honour our configuration
settings. People can and do change the layouts for various reasons, I do
ue causing scripts to fail.
The original code here checked for return codes of functions
which no longer set xx. As far as I can tell the best thing is
to simple remove the seemingly erroneous test and make things
deterministic!
Signed-off-by: Richard Purdie
You can view, comment on, or merge
Closed #447.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/447#event-1667062111___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
Reopened #447.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/447#event-1668108516___
Rpm-maint mailing list
Rpm-maint@lists.rpm
I realised there was a block further back in the code which sets xx =
setenv("PATH", path, 1); unconditionally so at the very least my patch
description is wrong. I think there is some questionable code here and would
welcome an opinion on what it should be doing.
In our local usage in Yocto Pro
Reworded the commit message.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/447#issuecomment-395362253___
Rpm-maint mailing list
