Skip Menu |
 

Date: Wed, 31 May 2006 10:50:55 -0400 (EDT)
From: Ezra Peisach <epeisach@MIT.EDU>
To: krb5-bugs@MIT.EDU
Subject: krb5-1.5 alpha - should library version numbers be bumped?


Should the library versions be bimped on the shared libraries?

With the plugin architecture - I suspect that we will have compatibility
problems on at least libkdb5... The export lists between the old and
current library versions are very different....

The gssrpc library has changed - functions have gssrpc_.... prepended -
so the libraries are definitly incompatible...


The krb5 library no longer has gmt_mktime, krb5_free_ets, krb5_free_uio,
krb5_init_ets, krb5_setenv, krb5_unsetenv.... The krb5_init_ets might
break really old code...

The k5crypto has lost krb5_random2key

libcomerr has lost add_to_error_table, free_error_table,
init_error_table, initialize_error_table_r... - but I think we are ok...


So - at least - we need a bump on libkdb5, libgssrpc... Maybe on
k5crypto and libcommerr....

Ezra
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #3821] krb5-1.5 alpha - should library version numbers be bumped?
Date: Mon, 5 Jun 2006 19:21:53 -0400
To: MIT Kerberos RT <rt@krbdev.mit.edu>
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3KiB
On May 31, 2006, at 10:51, Ezra Peisach via RT wrote:
Show quoted text
> Should the library versions be bimped on the shared libraries?
>
> With the plugin architecture - I suspect that we will have
> compatibility
> problems on at least libkdb5... The export lists between the old and
> current library versions are very different....

Hm, yeah, I should check on that...

Show quoted text
> The gssrpc library has changed - functions have gssrpc_....
> prepended -
> so the libraries are definitly incompatible...

A 1.4 source tree I'm looking at has gssrpc_ on all the names in the
export list. What old version are you looking at?

Show quoted text
> The krb5 library no longer has gmt_mktime, krb5_free_ets,
> krb5_free_uio,
> krb5_init_ets, krb5_setenv, krb5_unsetenv.... The krb5_init_ets might
> break really old code...
>
> The k5crypto has lost krb5_random2key
>
> libcomerr has lost add_to_error_table, free_error_table,
> init_error_table, initialize_error_table_r... - but I think we are
> ok...

I think these have been considered internal interfaces for some time,
so their disappearance just means we're tightening up. We decided a
while back that we only cared about the symbols in the public API --
we'll redefine, hide, or delete private symbols without changing the
major version number, and just assume the libraries and MIT's
programs will be from the same release.

Ken
Date: Mon, 5 Jun 2006 19:42:02 -0400 (EDT)
From: Ezra Peisach <epeisach@MIT.EDU>
To: Ken Raeburn via RT <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #3821] krb5-1.5 alpha - should library version numbers be bumped?
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.5KiB


On Mon, 5 Jun 2006, Ken Raeburn via RT wrote:

Show quoted text
> On May 31, 2006, at 10:51, Ezra Peisach via RT wrote:
>> Should the library versions be bimped on the shared libraries?
>>
>> With the plugin architecture - I suspect that we will have
>> compatibility
>> problems on at least libkdb5... The export lists between the old and
>> current library versions are very different....
>
> Hm, yeah, I should check on that...
>
>> The gssrpc library has changed - functions have gssrpc_....
>> prepended -
>> so the libraries are definitly incompatible...
>
> A 1.4 source tree I'm looking at has gssrpc_ on all the names in the
> export list. What old version are you looking at?

I am looking at a redhat system - looks like it is 1.3.4 - so maybe this
is not an issue..

Show quoted text
>
>> The krb5 library no longer has gmt_mktime, krb5_free_ets,
>> krb5_free_uio,
>> krb5_init_ets, krb5_setenv, krb5_unsetenv.... The krb5_init_ets might
>> break really old code...
>>
>> The k5crypto has lost krb5_random2key
>>
>> libcomerr has lost add_to_error_table, free_error_table,
>> init_error_table, initialize_error_table_r... - but I think we are
>> ok...
>
> I think these have been considered internal interfaces for some time,
> so their disappearance just means we're tightening up. We decided a
> while back that we only cared about the symbols in the public API --
> we'll redefine, hide, or delete private symbols without changing the
> major version number, and just assume the libraries and MIT's
> programs will be from the same release.
>
> Ken
>
>
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #3821] krb5-1.5 alpha - should library version numbers be bumped?
Date: Mon, 5 Jun 2006 19:46:09 -0400
To: MIT Kerberos RT <rt@krbdev.mit.edu>
RT-Send-Cc:
On Jun 5, 2006, at 19:42, Ezra Peisach via RT wrote:
Show quoted text
> I am looking at a redhat system - looks like it is 1.3.4 - so maybe
> this
> is not an issue..

Well, it still wasn't supposed to change ... when you look at the
symbols actually declared in the headers. (Minus those inside the
"KRB5_PRIVATE" blocks, etc.)

Ken