Jay, On Sat, Jan 04, 2003 at 09:14:06PM -0500, Jay Bonci wrote:
> I thought about this very same thing before putting this up for > packaging. My reasons are as follows: > a) I am working on a project that wants krb5 support, and I figured I > could option krb4 support as well > b) Debian already has a lot of libraries and support for krb4 clients. > it is legacy and this is not a reason in and of itself, but it is > compelling(in my mind) for inclusion in the archives. > c) The packages have not changed in a year or two on CPAN which says to > me that they are pretty much FINAL. With not a lot of code delta, I > don't expect them to be a burden on myself (or theoretically the QA team > or a future maintainer). I don't know how Debian feels about including > the "low hanging fruit", as I'm new at this, but I'd like your opinion > on it. > Also, as an option, since they are by the same author, I could package > them together, but my gut instinct says to have them separately. The following text is from the (AFAIK, still a draft) Debian Kerberos policy, which I agree with: If you are considering enabling Kerberos version 4 support, you should do so only if users of your package are in Kerberos version 4 environments or if users are choosing to build from source rather than use your package because of the lack of Kerberos version 4 support. There are many users of Kerberos version 4 POP, IMAP, CVS and Ssh, so if your package implements one of these protocols it is probably worth enabling Kerberos version 4. IOW, since Kerberos 4 has known security weaknesses and is a dying, non-standard technology, you should only implement Kerberos 4 in packages if there is a specific demand for it from users. As for this being a low-maintenance package, in the long term, I believe the maintenance cost of a package with no users (which is how this package sounds to me at present) is always too high. Regards, -- Steve Langasek postmodern programmer
pgpmXpTOyJc09.pgp
Description: PGP signature
