Stanislav Brabec wrote:
Ludwig Nussel wrote:
Johannes Meixner wrote:
I don't know if the ':-)' was meant for the whole paragraph. If not, what you wrote is - as far as I see - a total misunderstandig of what Stanislav Brabec meant. Using whatever check-tool on top of RPM is the totally wrong way to "solve" any intrinsic problem in RPM.
I had the impression that there is some frustration that even basic policy changes aren't fully enforced after years. I wanted to remind that someone has to step up and just do it in those specific cases mentioned above.
Even such simple policy change needs years to complete just because rpm has no way to do it globally.
Depends on the policy you change. There are a lot of knobs in /usr/lib/rpm/macros. %run_ldconfig is an additional knob in SUSE. Obviously it was simple to change it from doing something stupid to just calling ldconfig. If calling ldconfig becomes deprecated tomorrow you can globally change it to something else, rebuild, done.
All packagers are involved and every one has to complete the task for all maintained packages: grep ^%run_ldconfig */*.spec | wc -l 359
for/getpac/sed/submitpac :-)
How many years would take enabling of final force-fail check for Fedora incompatible packages?
No idea but that has nothing to do with rpm. You'd have the very same problem with any other system if you have to modify thousands of legacy packages in two projects with different origins.
Here is an example from class based build system:
openembedded/classes/package.bbclass, line 662: postinst += bb.data.getVar('ldconfig_postinst_fragment', d, 1)
Changing of ldconfig_postinst_fragment value you will change this policy for all packages in the whole distribution.
New policy can be enforced in less that one minute.
What does that prove exactly? Do you want to say the one who decided years ago that everyone needs to put %run_ldconfig calls in %post was mistaken and the correct implementation would have been to always have %post call ldconfig automatically? I have no idea what a 'class based build system' is supposed to be. However if you e.g. want to automatically have different post install scripts for certain kind of packages you'd have to tag your packages first and then have macros insert different scripts according to the tags definition. You can have that with rpm too. It's just that we have thousands of packages that have no tags. Even more clever than having ldconfig calls in post install scripts would be if rpm could call an appropriate post installation action automatically according to package contents. After all it already knows that the package installs stuff to e.g. /usr/lib or /usr/share/info so it could call ldconfig/install-info etc automatically. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org