[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Versioned Symbols

On Sun, 09 Mar 2003, Sam Hartman wrote:
>     >> I think that we should implement versioned symbols.
>     Anthony> Uhh, versioned symbols means that programs built on
>     Anthony> Debian systems won't run elsewhere. That's not something
>     Anthony> we should be doing, except in very specific cases where
>     Anthony> the gain outweighs the drawback.
> I believe that the gain outweighs the drawback in any core library
> that can drag in plugins unrelated to the application.  In particular,
> I believe that versioned symbols should be used at a minimum for
> dependencies of SASL plugins, PAM modules and NSS modules.

Agreed.  As far as "programs build on Debian systems won't run elsewhere",
it is just a matter of pushing the versioning of said core libraries to the
LSB, which shouldn't be too difficult if we do it right and send in patches.

> Certainly in cases where we want to add versioned symbols we should
> work as hard as possible with the upstreams to accept these changes.

Indeed.  Here's a plan of things to do for that to happen (based on my
experience with SASL upstream):

1. Write an autoconf macro that handles detection on the availability
   of symbol versioning in a platform.  Document the procedure so that
   we can send the algorithm instead for upstream not using autoconf.

2. Write an autoconf macro that changes the libtool variables needed
   to version something.

3. Write an autoconf macro that sets the linker/cc options needed to
   version something.

4. Send a full patch upstream that is plug-and-play, and defaults to
   versioning enabled where available.

5. Always use a non-dumb version prefix of "IDmajor" such as "SASL2"
   in the proposed patch (or "ID_major", or minor variations of that),
   using a proper ID that won't cause headaches later. CMUSASL2 would
   be another example of a good ID for Cyrus SASL versioning.

6. Send email to d-d-a with a url where we document all the issues
   with versioning, their workarounds, and our sample scripts. Send
   email to contacts in other linux distributions with said url.
   Push it at the LSB mailing lists, with a proposal of the core libraries
   that need versioning first and foremost.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply to: