Hi,
I want to share my thoughts about RPM.
Currently, when a lib is installed, it runs ldconfig, but it could be done in a smarter way.
When few libs are installed, every one calls "ldconfig" and that's slowing down transaction without special reason.
Lib, instead of running ldconfig, could set special variable, using RPM macro %ldconfig.
Code run by the macro:
| if [-e LDCONFIG] then | case "$LDCONFIG" in | 1) exit 0;; | 0) export LDCONFIG=1;; | *) ;; | esac | fi
This code might not be valid, but you can easily understand it's logic:
* if variable exists, value is checked;
* if it is already set as enabled, nothing is done. If isn't enabled, script enables it.
Same for gtk-update-icon-cache, but with GTK_UPDATE_ICON_CACHE variable for example.
After transaction some kind of rpm_config (name similliar to rpm_check_debug) could be run and update all the caches etc.
Idea was taken from openSUSE. They made this with SuSEconfig scripts, but can have same idea with better implementation.
On 25/03/2008, Jakub 'Livio' Rusinek jakub.rusinek@gmail.com wrote:
When few libs are installed, every one calls "ldconfig" and that's slowing down transaction without special reason.
In all seriousness, ldconfig is not much of a pig (once it's run, repeated runs tend to be much quicker, and if libraries were just installed, all the data needed is probably cached unless you have a *very* memory-starved machine. You'd be better looking at the various "update all the .desktop and icon files" programs run by gnome and kde packages.
Dnia 25-03-2008, wto o godzinie 16:19 +0000, Bill Crawford pisze:
On 25/03/2008, Jakub 'Livio' Rusinek jakub.rusinek@gmail.com wrote:
When few libs are installed, every one calls "ldconfig" and that's slowing down transaction without special reason.
In all seriousness, ldconfig is not much of a pig (once it's run, repeated runs tend to be much quicker, and if libraries were just installed, all the data needed is probably cached unless you have a *very* memory-starved machine. You'd be better looking at the various "update all the .desktop and icon files" programs run by gnome and kde packages.
I only mention ldconfig, because I had to update many libs today ;) .
The .desktop files are freezing my system everytime they are installed...
Slow or fast computer - doesn't matter...
I mentioned icon cache with GTK_UPDATE_ICON_CACHE.
BTW, what do you think about such solution, I described?
On 25/03/2008, Jakub 'Livio' Rusinek jakub.rusinek@gmail.com wrote:
The .desktop files are freezing my system everytime they are installed...
Slow or fast computer - doesn't matter...
That's always been my experience (and things like icons and .desktop files are far less likely to be vitally important to the running of other scriptlets than libraries).
I mentioned icon cache with GTK_UPDATE_ICON_CACHE.
Sorry, yes, I managed to not actually notice that first time around :-$
That seems to be a much bigger hog (and kbuildsycoca, too alas). There seems to have been a big improvement in the performance of adding or removing gconf schemas over the years, luckily, that's another timewaster.
BTW, what do you think about such solution, I described?
I'd like to see something like your description (logrotate has a similar concept with its "sharedscripts" flag when an application (possibly) handles many files e.g /etc/logrotate.d/rsyslog).
This is (unsurprisingly) one of those things that is brought up occasionally and usually we're all too afraid of the consequences of getting it wrong to change anything :o) plus tbh, it's hard to think of a good syntax for it.
Dnia 25-03-2008, wto o godzinie 17:13 +0000, Bill Crawford pisze:
On 25/03/2008, Jakub 'Livio' Rusinek jakub.rusinek@gmail.com wrote:
The .desktop files are freezing my system everytime they are installed...
Slow or fast computer - doesn't matter...
That's always been my experience (and things like icons and .desktop files are far less likely to be vitally important to the running of other scriptlets than libraries).
I wonder if this part can be reviewed... KDE doens't have such freeze when installing apps.
I mentioned icon cache with GTK_UPDATE_ICON_CACHE.
Sorry, yes, I managed to not actually notice that first time around :-$
Don't worry ;) .
That seems to be a much bigger hog (and kbuildsycoca, too alas). There seems to have been a big improvement in the performance of adding or removing gconf schemas over the years, luckily, that's another timewaster.
Try installing compiz-*gnome packages on Pentium 2 450MHz with 128MB RAM. What a suffering, what a pain!
BTW, what do you think about such solution, I described?
I'd like to see something like your description (logrotate has a similar concept with its "sharedscripts" flag when an application (possibly) handles many files e.g /etc/logrotate.d/rsyslog).
This is (unsurprisingly) one of those things that is brought up occasionally and usually we're all too afraid of the consequences of getting it wrong to change anything :o) plus tbh, it's hard to think of a good syntax for it.
When I was using openSUSE (and then get back with apologize to Fedora) I saw their SuSEconfig. I asked what is it for and it was interesting to me.
I didn't poke into their specs with ldconfig (and others) calls, but I think that replacing direct calls might be good idea and some improvement.
devel@lists.stg.fedoraproject.org
-
Bill Crawford -
Jakub 'Livio' Rusinek