Internalizing ldconfig also has other benefits, ie. if installing into a guest
host a non-native environment, an internal implementation of the most common
scriptlet which otherwise would fail because of installing distro environment
into an arm chroot, while host being x86_64.
In yocto, with
Agnosticism is fine.
Until (of course) rpm needs to handle multilib packaging, selinux policies,
debuginfo split binary/source packaging, etc.
--
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-
Implementing system details like ldconfig into rpm is not going to happen. We
try to keep rpm - especially the rpm core code - as agnostic of the operating
system it packages as possible.
Using file triggers here is not a perfect solution. Adding triggers that are
closer to the needs of ldconfig
Closed #405.
--
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/405#event-1518424665___
Rpm-maint mailing list
Rpm-maint@lists.rpm
In lib/rpm triggers.c rpmtriggersSortAndUniq():
The sort uses hdrNum, whose value can change when a package is removed and
reinstalled with
--justdb (and perhaps with --rebuilddb depending on backend) thereby causing
(at least) a different trigger firing order.
--
You are receiving this becaus
There's also redundancy from /lib -> /usr/lib symlink. Try using realpath.
--
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/405#issuecomment-370138436__
Yuck: file triggers are prefix match only, with no path canonicalization (I.e.
removal of multiple slashes etc). You could/should try using fnmatch through
rpmio/mire, which could be flipped to using glob/regex patterns by changing an
argument.
You likely also should forbid partial dir/file pat
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:
https://github.com/rpm-software-management/rpm/issues/405#issuecomment-370126290__
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 u
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:
https://github.com/rpm-software-management/rpm/issues/405
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 GitHub:
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:
https://github.com/rpm-software-management/rpm/issues/405#issu
(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 macroi
13 matches
Mail list logo
