True, that's something we might want to investigate. It depends a bit on where
rpm's bottleneck is. If it's IO bound, adding parallelism won't help much.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
Synchronous waits on scriptlet execution is entirely dead time.
Using a faster 256bit hash like BLAKE2 speeds up a large bottleneck.
Using compressions (like zstd) that are faster to decompress outperform xz.
None of what I just mentioned needs threading.
Meanwhile guessing at I/O bound, or
In the interest of moving away from guesses to measurement, I point out the
--stats option that can be used from the rpm CLI. Rpm is heavily instrumented,
and --stats can be used to at least provide some indication of the cost/benefit
of a given change.
--
You are receiving this because you
You probably didn't read it carefully:
https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc.spec#_443-455
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
For example: those triggers do not handle ld.so.d/* files that also change
ld.so.conf contents from alternative paths.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
And you probably do not understand the additional overhead that file triggers
impose on installation times, nor the flaws that will inevitably appear in the
file trigger code.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
(After reading through many complaints about ldconfig overhead on fedora-devel@
...)
RPM has all the necessary information in header metadata to precisely perform
what ldconfig does only when necessary without any assistance from
/bin/ldconfig or packagers.
While the recent proposals to
Ok, I've now caught up with the bugzilla discussion, including that you have
decided to deploy an incomplete solution and not handle ld.so.conf.d changes
(though all the bizarre variants and performance were noted and discussed).
IMHO it's still easier to just handle symlink creation and cache
Well, if you will submit PR I would definitely look at it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #375.
--
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/issues/375#event-1500803808___
Rpm-maint mailing list
Is this supported? If not, what work needs to be done to implement it?
--
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/issues/404___
Closed #404.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/404#event-1500826006___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
They say it does not:
https://github.com/openSUSE/zypper/issues/154#issuecomment-369875793
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
I think the question is not if two versions of a package may be installed, but
if the install itself can be done in parallel. I.e. if two 'rpm -U' calls can
be done in parallel. That won't work because of the global transaction lock.
And I don't think we should change this. ;)
--
You are
sign_hash is in the external libimaevm. But it shouldn't be needed if you don't
try to build with imaevm support.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #403.
--
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/issues/403#event-1500834651___
Rpm-maint mailing list
There is (of course) the third meaning of "in parallel":
Q: Can a single invocation of "rpm -U" install/erase packages in parallel while
holding the global transaction lock?
A: Not yet.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
FYI: The largest impediment to doing multi-threaded installation is preserving
the order in which callback messages are delivered since many applications
using rpmlib are triggering actions (like progress bar updates) from callbacks.
--
You are receiving this because you commented.
Reply to
18 matches
Mail list logo
