Bugzilla Bug 137438

Emerging mit-krb5 with berkdb in the use flags (default, I believe) results in
passing --with-system-db to the configure script.

Quoting from the MIT install documentation,

--with-system-db
    Use an installed version of the Berkeley DB package, which must provide an
    API compatible with version 1.85. This option is unsupported and untested. 
    In particular, we do not know if the database-rename code used in the 
    dumpfile load operation will behave properly.

For production installations, it would seem a better choice to use the fully
supported and tested bundled DB library rather than the local system version.
This is easily resolved by adding -berkdb to /etc/portage/package.use for
mit-krb5, but it seems wrong to have the typical default installation result in
an unrecommended by upstream configuration.

So don't use USE=berkdb? Or what's you point here? Someone forcing you to use
it?
You've filed four bugs that are not really bugs but rather points to discussion
in five minutes. Move it to mailing list. Thanks.

Jakub, please exercise some patience and tact when dealing with users.

I've been using Gentoo for fun for the last couple of years,and while reading
the mailing lists and perusing the bug database, haven't really had any
involvement. I'm currently working on developing an infrastructure for my
campus using Gentoo, and will probably generate more messages/bugs as I
progress. I have some handle on accepted etiquette, but no one's perfect and as
time progresses hopefully will become more attuned to how developers want
things handled.

Jakub, could you possibly clarify why you are so upset about the bugs I filed
so I could better understand why you feel this was not an appropriate way to
communicate these issues?

Are you most upset because you feel these four issues should have been
discussed on mailing lists? From lurking on the developer mailing list for the
last year, it seems most of the issues discussed therein are high level things
that impact the majority of the developers or are of high significance. These
particular four issues I did not think would interest very many subscribers to
the mailing list, but most likely only be a concern for developers actively
maintaining Kerberos. It seemed the best way to target those developers was to
file a bug assigned to them. If they felt the issue deserved wider discussion,
they could start a dialogue with whomever they felt appropriate. I also thought
the tracking/search capabilities of the bug database where more appropriate for
this than mailing list archives for anyone in the future investigating similar
issues. 

Are you upset because I filed four separate bugs? While perhaps in the context
of a mailing list message they could have been combined, as bugs it seemed the
most appropriate to file them separately. Each one stands alone and has no
dependencies on the others. Each one can be discussed independently, and the
decision whether or not a particular one is worth following up on has no impact
on such a decision for the others.

Is it because I filed all four in rapid succession? I suppose I could have
artificially induced a delay between filing each bug, but for what purpose?

Do you feel that each of the four issues are too trivial to warrant a bug
report? One of them results in a configuration considered unsupported by
upstream, two of them have security ramifications, and the last seems to be an
inconsistency with how data files are handled by other packages. Perhaps I am
mistaken, but each of them seemed worth at least a little discussion.

Guys,

let's forget the early stuff and concentrate on the issues at hand in the bug,
instead.

(In reply to comment #1)
> So don't use USE=berkdb? Or what's you point here? Someone forcing you to use
> it?

As I indicated in my original report, I have already resolved this issue for my
installation by adding -berkdb to /etc/portage/package.use for mit-krb5. This
is great for me, but my *point* is that a default installation of Gentoo will
result in an MIT Kerberos 5 configuration that is considered unsupported by
upstream. This hardly seems desirable. I generally operate under the assumption
that anything resulting from a default configuration is the "best" general
solution as determined by the Gentoo developers. That assumption seems violated
in this case, and unless a user reviews the MIT installation documentation, and
compares that to the ebuild, they won't realize they have a potentially
problematic install.

It would seem that ebuilds which consider the berkdb use flag fall into one of
two groups:

* The application has optional bdb support, which will be compiled in if use
berkdb is set, or not compiled in otherwise.

* The application requires bdb and will support use of a locally included
implementation if a version is not already installed on the system. In this
case, use berkdb will cause the ebuild to make the appropriate choice.

MIT Kerberos seems to fall into neither of those groups. It requires bdb, and
while it does have an option to use a system installed bdb library rather than
the bundled one, the installation documentation says that is not recommended,
not tested, and will result in a configuration not supported by MIT.

My initial impression is that the ebuild should simply ignore use berkdb, and
always install the bundled one, as I don't think many users would want an
untested and unsupported configuration for a critical piece of infrastructure.
Barring that, it would seem at least an ewarn is warranted informing the user
that their current configuration is potentially problematic.

Since upstream does not support this configuration I am in favour of always
using the bundled db; are there any collisions with sys-libs/db with -berkdb ?

I have both sys-libs/db-4.2.52_p2-r1 and app-crypt/mit-krb5-1.4.3 (with
use=-berkdb) emerged with no problems or complaints.

It looks like the bundled implementation of db is installed as libkdb5.so,
which doesn't conflict with anything.

fixed in mit-krb5-1.4.3.-r2, thanks.

Fixed in this case means: totally break existing installations that used the
system db.
Not even a warning suggesting to dump the Kerberos DB with kdb5_util before the
update and then restore it afterwards..