Curiosity aside, as generally noted this is not right from upstream
perspective. NAK.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #251.
--
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/251#event-1313760753___
Rpm-maint mailing list
I'm actually curious as to what the use-case for this patch is, because at
least with the cli tools of rpm itself, queries and the like have "always"
stopped fast enough with the existing polling mechanism.
Now that transactions run with signals blocked, we could move the signal polls
into the
I'm happy it works fine for SuSE: I'm sure you have tested.
Meanwhile ^C exiting and calling rpmdbClose is a problem that needs to be
solved without convoluted BDB configuration changes. Its tiresome to
continuously revisit this issue, in patches and bug reports.
--
You are receiving this
Trust me, the patch works fine for the setup used at SUSE. But I agree that it
makes no sense to merge it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mischroe: DB_PRIVATE has its own associated durability/signal problems,
including that ^C is masked while installing, and with the transaction lock
being for exclusive writers, not readers.
Truly ^C handling needs to be solved intelligently, not with convoluted
contortions to BDB
Just a note to remember that for generating new roots (i.e. not inplace
upgrades), we can just let SIGINT kill us. For rpm-ostree, every operation is
a new root, so we [turn off rpm's SIGINT
I guess thats something else we should upstream or standardize with upstream on.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
(It works for SUSE because we always open with DB_PRIVATE and thus don't use
the dbenv at all. So there's no ignorant denial involved ;-) )
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Sigh ... there are much better fixes for ^C handling than reopening an rpmdb
(where ^C will *still* be disabled while installing).
For starters, the signal handling in RPM was designed to be polled at code
points where the rpmdb is known to be consistent (for a graceful exit with an
rpmdbClose
Ok i'll update the commit message as a starting point, the original patch was
quite different but it doesn't seem like this has been covered in the latest
version.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It's done so that ^C exists rpm if in read-only mode. I don't know how it
interacts with the db-env, SUSE only uses DB_PRIVATE.
Panu also changed the signal handling quite a bit recently, so it may well be
that the patch is no longer needed.
--
You are receiving this because you are
I would be happy if commit message was explaining problem... Though code looks
good
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
13 matches
Mail list logo
