Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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 rpm5 all common, simple unix tools was maintained as natively built versions of what's available in non-compatible guest environment. Thus when initializing environments by installing into a chroot, binaries built host compatible can be run in scriptlets. With this in addition of what @n3npq proposes as rationale, I'd be very much interested in seeing a first internal ldconfig implementation if possible before a lua implementation. :+1: -- 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-372927520___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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-management/rpm/issues/405#issuecomment-372764601___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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 may be an option in the future. A way to save execs could be reimplementing ldconfig as lua scriptlet. But both of these options are different things than this RFE. Closing. -- 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-372644372___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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 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-370176488___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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 path matches so, say, /liberal /libation /lib64 are not all matched by /lib. One easy way to do that (with prefixes) is by appending a /. Further yuck: there are way too many matches retrieved by file triggers that are uniqified down to a single trigger execution. -- 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-370138233___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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 update as a direct side effect of installing a DSO file. No lua, no database retrievals, no fork/exec (and close(fdno) overhead), no obscure abstractions, no false runs when some directory is changed by a non-DSO install. The place to do so is immediately after temp files are renamed into place in what (used to be) lib/fsm.c. I would also not bother packaging symlinks into headers, but rather leave the creation/removal as part of DSO handling. Note that embedding ldconfig into rpm would also permit a --verify implementation -- 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-370119038___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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#issuecomment-370053250___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#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: https://github.com/rpm-software-management/rpm/issues/405#issuecomment-370052194___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
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#issuecomment-370048511___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: Fully automate ldconfig handling within rpm (#405)
(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 macroize (and hence standardize) /bin/ldconfig invocations in scriptlets are perfectly sane, the problem(s) of install overhead, due to exec(2) closing open fdno's, and excessiv invocations, cannot be solved with Newer! Better! Bestest! macros and packaging policy enforcement. If anything, the change to add fsync/fdatasync to /bin/ldconfig cache handling are surely going to increase the overhead https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=elf/cache.c;h=e63979da7d25560c4072cca99749e879005c5c2f;hp=c2c010f97bb23d2b568e6499e5806dac73211da3;hb=999a6dab3ee1c8e77bb348ba2389e7aeb5c062b2;hpb=52a01100ad011293197637e42b5be1a479a2f4ae Internalizing /bin/ldconfig in rpm is quite feasible: it's not difficult to add symlinks and maintain a cache file in sync with changes performed by RPM thereby fully automating the operations as a side effect of installing a DSO from an rpm package. In fact, that is exactly what the FreeBSD pkg command does: https://github.com/freebsd/pkg -- 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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint