On 05. jún 2003, 15:31, Florin wrote: > > my idea is: recompile all these packages without kerberos support and > > make decision about policy that we don't want kerberized packages into > > main. after this, move all main krb (libs + apps) stuff to contrib. > > if someone want kerberized version, then he can rebuild packge > > --with-krb or similar.. > > so your idea would be to remove all kerberos in the contribs ... > recompile all the packages without kerberos ... the eventually recompile > them again if somebody want them ... remove kerberos support at install > > hmm,
i know, this is too strong but if you don't like it, there is another (maybe clearly) solution for this. add a pam_krb5 module to pam package (this module exist, check: http://www.kernel.org/pub/linux/libs/pam/modules.html -> Kerberos) and implement kerberos authentication mechanism via pam, not via directly linking kerberos libs into daemons.. i think this is crystal clear solution to non kerberized enviroment. if someone want krb5, then change configuration of desired application and add this into pam configuration file (this is similar like ldap authorization, or sql or radius, or something else..) > ... and move your ftpsomething package from contrib to main ? this is not required :) it was only my tip to "default" ftp client only. i only want to tell, that i think: directly linked kerberos libraries into apps isn't clear solutions and systematic for some systems which want krb5 support.. it can be "optionally", not "by default".. -- member of Advanced InternetWorks group -> http://www.ainetworks.sk professional home page -> http://tibor.pittich.sk personal home page -> http://c0re.phuture.sk
pgp00000.pgp
Description: PGP signature
