Update manager : ldconfig error message

[melodie]

Hi,

Lors de l'installation du paquet cmus-2.4.1-1pclos2011 :

Warning in file "/usr/share/applications/pcmanfm.desktop": usage of MIME type "x-directory/normal" is discouraged ("x-directory" is an old media type that should be replaced with a modern equivalent)
/var/lib/rpm/filetriggers/ldconfig.script: line 2: ldconfig : commande introuvable

in short : ldconfig : command not found.

I this thread : [Someone to help test from page 5 ?] Apt-sources-update ? (Re Open)

I have suggested (at page 4 I think) an alias from synaptic to gksu -l synaptic, or something like that, to cure theses issues.

Any other ways of fixing it welcome of course. Thanks for fixing it.

Regards,
Mélodie

[ongoto]

This problem keeps re-appearing.

AS suggested:
http://www.pclinuxos.com/forum/index.php/topic,94406.msg802286.html#msg802286

Neal suggested:
http://www.pclinuxos.com/forum/index.php/topic,94896.0.html

Others have suggested PATH mods in ~/.bashrc and bash and there have been
several more.  

There are nice installers and there are mean ones.
I have to go along with AS. Other fixes unplug the warning light but yield to the
problem.  They allow the installers to inherit root privileges, giving
them carte-blanche, and most only work from synaptic, not apt-get.

/bin is in the 'path' of most software.
I suggest a link in /bin pointing to /sbin/ldconfig:
ln -s /sbin/ldconfig ldconfig  
This exposes only ldconfig, not the entire system.  

Installers will find the link and assume no dangerous privileges or cause any bad side effects.  
There's no need for any complicated scripts or patches or mods to ldconfig itself or users having
to modify launchers, etc..  
Works 4 me.

What do you think?  

[muungwana]

There seem to be a bug here introduced by a package not that many people have it installed that produce this error. Work arounds have been suggested but a reason why this happens is still not known.

When did you first notice the problem? Can you go back to synaptic and check installation history around the date and check what packages were installed/updated?

[melodie]

Hi,

It appeared with the new apt-common/apt/synaptic toolchain. In Bonsai 2011 under test, once I had changed the Exec command in the desktop file from "gksu -u root synaptic" to "gksu -l synaptic" it seemed to be solved as the message was not appearing anymore.

ongoto : I don't know. I have no idea if there is any danger or not in linking ldconfig so that it is in the /bin directory. What I know is we would better get a solution that could be implemented in the community versions officially approved (or just in the programs that trigger the error message). I mean, if each user does his little cooking in his system, that might not be the best way to solve it.

There is the program Update Package Source List (apt-sources-update) done by Leiche who suffered from the same problem. I have not have time to test the very latest yet, I'll do that now.

[ongoto]

Just for the sake of discussion.....

Sudo is blacklisted by PCLOS for good reason.  Tweaking gksu to do the same as sudo can't be good either.  It may hide an error during installation, but what about later?
 
ldconfig maintains a cache of links so that applications can find their libraries quickly.
If an application needs to use the cache while it's running, how will it find it?  It won't unless it is running in a root environment.  ldconfig also can take several options when it's called. ( ldconfig -p  shows the cache )

There may still be a better way, but a link serves the purpose at install time as well as run time.  It will pass the call, and the arguments as well, without interfering or requiring any special change in privileges.

nvidia uses ldconfig as well as Leiche and many others that have been mentioned over the past year or so.  If a video driver can't find it's libraries, would the CPU and the kernel take over the job?  or would it be handed over to vesa?  I dunno.

[AS]

Hi ongoto,

About to link /sbin/ldconfig to /bin/ldconfig:
No: /sbin (system bin) exist for the only reason of separate system command (in /sbin) from user commands (in /bin)

about library cache: it's built from /sbin/ldconfig in /etc/ld.so.cache, and it's readable from all users:

-rw-r--r-- 1 root root 125344 Aug  4 20:48 /etc/ld.so.cache

only the execution of the ldconfig command is restricted to the administrator.

For discussion:
I have seen some spec file that include the ldconfig and there is specified as /sbin/ldconfig, may be that in some package this is not the case, very probably the single package spec file should be fixed.

Additionally, had just noticed that on my system an unprivileged user define and add /sbin to the PATH, I think this is not correct, and is it seems to me that is different depending on PCLinuxOS flavor. This last point need further examination.

AS

[ongoto]

AS

about library cache: it's built from /sbin/ldconfig in /etc/ld.so.cache, and it's readable from all users:

I see.  So once the lib link is in the cache, it is available to all.  That's good.

I modified my system also to include /sbin in the users' path, but I still get the ldconfig warning in synaptic and apt-get as well.  So it does no  good, really.

You mentioned the spec file in some applications.  Do those with the full path ( /sbin/ldconfig ) work correctly?  If so, it might be worth the time to rebuild the others.  There can't be that many!  I'd be willing to help if I knew how.

[melodie]

Hi,

Do you know ktsuss ? ktsuss is the equivalent of gksu or kdesu, but desktop independant, small, and light.

I just tried to use it from console, this way:

Code: [Select]

$ ktsuss synaptic
(We have it in our repos, I asked for a package some time ago and Texstar accepted to make it available).

The result is fine. I have removed and added applications, and I never got the ldconfig error message, at any moment. I emptied the apt cache, closed Synaptic, restarted it with the same command (it prompts you for the root password, of course) and again installed other packages, same result : no ldconfig error message.

The size is 43 Kb. Would you want to give it a try ?

[melodie]

PS: I also invite you all to look here : http://www.pclinuxos.com/forum/index.php/topic,94406.msg802999.html#msg802999

^^

[ongoto]

RE: the ldconfig thing

I've been testing this forwards, inside-out and backwards, and I'm almost
convinced that we are being handed a 'false positive' by apt and synaptic.
Even though there is a warning, the ldconfig cache is being updated correctly.
I'm seeing the same changes whether I login as root or as a user.  I've done it
in virtual terminals as well as ttys and with synaptic.  If I remove a package,
the lib link goes away.  If I install, it comes back.  No difference, warnings
or no warnings. 

I checked the difference in the cache when removing Leiche's app.  Absolutely
no change.  I wonder if he actually has a library that is being linked?  If not,
then he has no worries as far as ldconfig is concerned.

I think ldconfig is working like it should and, if I'm not missing something,
that the warnings are rubbish.
-------------

Hi Melodie

Yes, thank you.  I'd like to try it.  I'll let you know.   
------------

[melodie]

I think ldconfig is working like it should and, if I'm not missing something,
that the warnings are rubbish.

Exactly. I didn't check the same way as you but noticed that none of the apps I installed that triggered this error message had problem. All of them work perfectly. If you are right and "gksu -l" be a substitute to sudo, then it might be a bug from gksu... perhaps. ktsuss does not present a bug (and now I'm looking to next ktsuss version which is not a checkout svn at Google.code... )

[Neal ManBear]

Is "gksu -l" a substitute for sudo? I thought the difference between "gksu -u root" and "gksu -l" was like the difference between "su" and "su -." Did I miss something?

[melodie]

Is "gksu -l" a substitute for sudo? I thought the difference between "gksu -u root" and "gksu -l" was like the difference between "su" and "su -." Did I miss something?

This has been suggested somewhere on the forums by ongoto... I have no certainty and I am expecting to read more information about it. One thing is sure, is that adding "ktsuss" in front of the 2 synaptic commands did make the script apt-sources-update of a former version work fine and got a nice little window to be prompted.

Another thing is that next week I might be able to go to package requests for an update of ktsuss. (I wait for the right version number to be shown and a changelog file in the sources)

[AS]

Is "gksu -l" a substitute for sudo? I thought the difference between "gksu -u root" and "gksu -l" was like the difference between "su" and "su -." Did I miss something?

Surely I myself, if not you, was missing the sudo relationship with gksu.

"gksu -l" correspond to "su -"
su --help:

  -, -l, --login               make the shell a login shell

man gksu:

       --login, -l
              Make  this a login shell.

about su vs. sudo, from gksu manual:

       Notice that all the magic is done by the underlying library, libgksu. Also notice that the library will decide if  it  should
       use  su  or sudo as backend using the /apps/gksu/sudo-mode gconf key, if you call the gksu command. You can force the backend
       by using the gksudo command, or by using the --sudo-mode and --su-mode options.

AS

[Neal ManBear]

Is "gksu -l" a substitute for sudo? I thought the difference between "gksu -u root" and "gksu -l" was like the difference between "su" and "su -." Did I miss something?

Surely I myself, if not you, was missing the sudo relationship with gksu.

"gksu -l" correspond to "su -"
su --help:

  -, -l, --login               make the shell a login shell

man gksu:

       --login, -l
              Make  this a login shell.

That is as I thought.

about su vs. sudo, from gksu manual:

       Notice that all the magic is done by the underlying library, libgksu. Also notice that the library will decide if  it  should
       use  su  or sudo as backend using the /apps/gksu/sudo-mode gconf key, if you call the gksu command. You can force the backend
       by using the gksudo command, or by using the --sudo-mode and --su-mode options.

AS

So then even though I do not use sudo, gksu can call it? Doesn't sudo use the user's password, rather than root's password?