I ran into this problem today, when I first tried to emerge heimdal to find that it was blocked by mit-krb5. Upon unmerging mit-krb5 I found that my wget was no longer working because it is linked against ssl which is linked against gssapi/mit-krb5. After re-emerging mit-krb5 (would've been nice to get a notification that i was shooting myself in the foot and would be real screwed if I didn't have mit-krb5 in /usr/portage/distfiles but I'm over it) I did a USE="-ssl" emerge --newuse -u wget and then proceeded to unmerge mit-krb5 and then emerge heimdal. Upon successful merging of heimdal I found that it was not a comparable replacement to mit-krb5 and leads me to believe that there was never really any reason that mit-krb5 should be blocking heimdal in the first place. For what it's worth, my only reason for deciding to try heimdal was not because of licensing but rather I found that the mit-krb5 package installs example configuration files in /etc that refer to directories that do not exist (incomplete ebuild?) And I do believe that it's very likely that since I didn't emerge mit-krb5 in the first place, that it's probably there because of the USE flag that I have set: 'kerberos' Also for what its worth, I'd be interested in stepping up and fixing the annoyances I have described myself if necesarry--I need to make ldap+kerberos happen one way or another-- please let me know. Reproducible: Always Steps to Reproduce: USE="kerberos ssl ldap etc etc" emerge lynx wget etc etc emerge --unmerge mit-krb5 emerge heimdal *blaaaah* emerge mit-krb5 USE="-ssl" emerge --newuse -u wget emerge --unmerge mit-krb5 emerge heimdal *blaaaaaaah* emerge --unmerge heimdal && emerge mit-krb5 USE="ssl" emerge --newuse -u wget ...back in the hole... Severity is at your discretion, the subjectivity of this vs. that makes me feel stupid. I'd be glad to help out if someone can merely confirm that help is needed, or at least point me in the right direction.
Yes, default is app-crypt/mit-krb5. Not every package supports heimdal, yet. Wrt. to the kerberos/ssl/wget issue, I don't think there can anything done about it, when the user decides to uninstall libraries under his fetch utilities hood. It's normally anot unrecoverable situation and at some point the users brain is requried. When you search bugzilla for heimdal, it's pretty obvious what you can do about it. ;)
(In reply to comment #1) > Yes, default is app-crypt/mit-krb5. Not every package supports heimdal, yet. > Wrt. to the kerberos/ssl/wget issue, I don't think there can anything done > about it, when the user decides to uninstall libraries under his fetch > utilities hood. It's normally anot unrecoverable situation and at some point > the users brain is requried. > When you search bugzilla for heimdal, it's pretty obvious what you can do about > it. ;) Sure, for heimdal that seems pretty reasonable. Though is it possible that I could at least try to get kerberos to default to heimdal instead of mit-krb5 if I were brave? The only other way I can think of would be to try things one at a time rather than letting portage do the work... As for the mit-krb5 example configuration files (krb5.conf.example and kdc.conf.example) I don't get those at all after re-merging mit-krb5 (and yes I deleted the old configuration files.) So maybe I fetched those from somewhere and forgot, or maybe that was fixed with an earlier update (but not really since it didn't delete them, didn't create any new ones either.) At any rate, I could've found my way out of the wget issue I had, and as I was discussing before on IRC with some of the portage folks it would be nice to know that it was potentially crippling to unmerge mit-krb5 due to the fact that wget would no longer work although testing on system identical to the target system is probably better than a more complex portage that knows what packages are critical given a certain USE="" configuration.
I am running quite a few machines on heimdal exclusively. It's important to use the kerberos overlay atm because the packages in tree are really outdated. But we are on it to get it into tree. But the switch from mit-krb5 to heimdal won't be easy in near future. It always means some kind of experience and knowledge. The overlay: git://git.overlays.gentoo.org/proj/kerberos.git g, mueli
g-- your URL returns a 404. Also I appreciate the insight though I've already decided to move forward with mit-krb5 despite the quality of the package available in the default portage tree. For what it is worth, I've already looked at layman and what's available (I assume thats what you're are referring to by overlays.) It seems to me that it would stand to reason to mask packages that are past their shelf life or have known unfixed sec-vulns like so: !!! All ebuilds that could satisfy "games-roguelike/nethack" have been masked. !!! One of the following masked packages is required to complete your request: - games-roguelike/nethack-3.4.3-r1 (masked by: package.mask) /usr/portage/profiles/package.mask: # Tavis Ormandy <taviso@gentoo.org> (21 Mar 2006) # masked pending unresolved security issues #125902 Although I may be get this message because I'm running gentoo-hardened.. not real sure.
sorry, just realized the git:// in front of that url you posted--maybe its not 404. yay for add
