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

Re: 2nd call: binary incompatibility



"Andrew G. Morgan" writes:
>I didn't get any feedback last time from Red Hat or Caldera, so here it is
>again..

I'm sorry.  I meant to reply.

As far as I'm concerned, the sooner we become compatible with the new API
the better.  Localization is clearly important, and we might as well make
the change while there are fewer modules to change, rather than waiting
until there are even more.

>In the former case, Solaris decided to require the pamh argument to be
>supplied to the pam_strerror() function.  We (in keeping with the PAM RFC)
>do not.

That's a change we should definitely make.  (It will probably cause me to
tear my hair out later, though.)

>The latter case concerns the pam_response structure and how it is filled. 
>In some cases they do as we do and in others we differ.

I'm assuming you will change misc_conv() to match when you make the
change, and I can move to using misc_conv() instead of my hacked-up
local versions.

However, I don't know what the difference is; I don't see the discussion
of this in the messages that discussed the pam_strerror() function earlier.
Could you elaborate?

In any case, remember to change the libpam soname when you make the change!

michaelkjohnson

"Magazines all too frequently lead to books and should be regarded by the
 prudent as the heavy petting of literature."            -- Fran Lebowitz




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