Steve Langasek wrote:
After reading your email (especially the last couple of sentences), it dawned on me as to what the policy is trying to say. Let me first tell how I interpreted it and then I will provide some possible improvement.On Thu, Jul 14, 2005 at 04:18:15AM -0400, kamaraju kusumanchi wrote:Can you tell me where in this section 8.1, does it say that the maintainer has to create a symbolink for a runtime library package? The thing that comes close is the following paragraph.The run-time library package should include the symbolic link that^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^|ldconfig| would create for the shared libraries.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm sorry, I don't see any way that Policy could be rewritten to make the very first sentence that you quoted any clearer.
From the above sentence, I initially thought thatldconfig would create the symbolic link for the actual shared library. The run-time library package then should include this symbolic link in it.
One possible alteration would be (with minimal changes to the original text)
The run-time library package should include the symbolic link to the shared libraries that| |would have normally been created by ldconfig. This link has to be created by the maintainer. For example, the |libgdbm3| package should include a symbolic link from |/usr/lib/libgdbm.so.3| to |libgdbm.so.3.0.0|. This is needed so that the dynamic linker (for example |ld.so| or |ld-linux.so.*|) can find the library between the time that |dpkg| installs it and the time that |ldconfig| is run in the |postinst| script.
Another possible alteration could be (completely rewritten)ldconfig can be used to create necessary symbolic links for a given shared object. However, it cannot be used to remove these symbolic links when the package is removed. For this reason, it is required to manually create and remove the symbolic link in the runtime library. Consider for example the libgdbm3 package which creates libgdbm.so.3.0.0. Normally running ldconfig on this, would create a file /usr/lib/libgdbm.so.3 which points to libgdbm.so.3.0.0. But for reasons suggested before, this link has to be created by the maintainer.
According to this paragraph ldconfig should take care of creating the links. Other replies to this thread suggest that ldconfig is not used for this purpose while packaging .debs. If that is correct, then section 8.1 of policy has to be rewritten (since it conveys wrong information).The *package* should *include* the *symbolic link*. I think Policy is already very clear on this point. Policy doesn't care how you get the symlink *into* the package, if that's what you're asking; it only requires that the symlink provided by the package be the same one that ldconfig *would* create.
That last sentence is what made me see the real meaning. thanks raju -- Kamaraju S Kusumanchi Graduate Student, MAE Cornell University http://www.people.cornell.edu/pages/kk288/