Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
Here it is a new ebuild for heimdal 0.7 and an updated patchset. I have fixed the ebuild and added a patch to make heimdal compile with krb4. I have excluded the following patches: 001_all_heimdal-ldap-subtree.patch 020_all_heimdal-snprintf-test.patch since the new version includes the respective fixes.
Created an attachment (id=62153) [edit] 002_all_heimdal-no_libedit.patch
Created an attachment (id=62154) [edit] 003_all_heimal-fPIC.patch
Created an attachment (id=62155) [edit] 004_all_heimdal-rxapps.patch
Created an attachment (id=62156) [edit] 005_all_heimdal-berkdb.patch
Created an attachment (id=62157) [edit] 006_all_heimdal-suid_fix.patch
Created an attachment (id=62158) [edit] 010_all_heimdal-system-libss.patch
Created an attachment (id=62159) [edit] 011_all_heimdal-kdc_fix.patch
Created an attachment (id=62160) [edit] heimdal-0.7.ebuild
Could someone explain me why must be heimdal installed in a NON-standard location? The standard is /usr/heimdal. I care because of this because lots of third-party application EXPECT it to be in this directory and have zillions of problems when it is mixed into /usr/include etc. It sucks, sorry! Look for configure of openafs, mozilla, pine, various POP3 and IMAP servers and their support for kerberos4 or 5. They look into /usr/athena (KTH-KRB4 package), /usr/heimdal. Only MIT KRB5 install into /usr/local, which sucks. In a few cases and when developers had the time to catch up with never versions of kth-krb4 and heimdal, they use /usr/heimdal/bin/krb5-config and similar to figure out the location of libraries and headers as well as the list of libraries required to link correctly apps. Make the life easier for people!
I can not accept the ebuild as it is, because you omitted the copyright and license lines from its header. Please reattach a version of the ebuild with more accurate information.
Created an attachment (id=63714) [edit] heimdal-0.7.ebuild (updated)
Created an attachment (id=63715) [edit] heimdal-0.7.ebuild (updated)
Stefaan, comment #9 is what you and I were just talking about -- any input here?
added into portage, thanks _ayin_ So, as for the file installation locations issue. We adhere to FHS standards. Broken packages need to be fixed. Third party packages which do not want to be fixed we'll have to think about. At the moment, the idea is a compatibility package for afs and perhaps heimdal, if need be.
It seems OpenAFS just looks for heimdal (using krb5-config) in $PATH, and uses that afterwards, no /usr/heimdal or similar hardcoded whatsoever. Also, after a quick look different distributions, I found RPMs of which one uses prefix /usr/heimdal, the other /usr/lib/heimdal, but Debian and BLFS use the /usr prefix, seemingly without any problems. In my opinion, if there is a need to use the /usr/heimdal path, the momentum behind it seems a bit small to violate standard gentoo behaviour for it. OSS-packages can probably be easily adapted to look for krb5 in the right place, just by adding gentoo patches, which could maybe be pushed upstream afterwards. If any proprietary third-party software requires legacy paths, this can probably be fixed by an extra compatibility package that imitates legacy-file locations by using softlinks, just as Seemant mentioned.
perfect, thanks stefaan!
I'm reopening the bug because: 1. the ebuild should depend on kth-krb-1.3 if krb4 is to be compiled in. There is only 1.3_rc1 snapshot on the KTH ftp site, but that's what I use and is ok. Explanation _why_ is a bit beyond this discussion, but as I have assemled now a _NOT_EVEN_YET_COMPLETELE_ :-) list of just heimdalrelated bugreports around in of those threads is explained by hard learning why openssl-0.9.7 and kth-krb-1.3 and heimdal-0.7 ... Not everything is a history and obsolete these days, at least that's my impression. You should also learn from those lessons how people struggled the bugs ... 2. Why do you create the soflinks for headers when you claim you can either explain to all other packages that --with-heimdal-headers=/usr/include/heimdal -with-heimdal-libs=/usr/lib ???. This will only cause confusion.: dosym heimdal/krb5-types.h /usr/include/krb5-types.h ... More on the --prefix discussion: You have to have plenty of time the for fixing other configure definitions first. I mean this should happen _BEFORE_ you install into non-standard place. ;) Just look at these bugs and keep in mind _some_ of them are caused just by people getting tired to handcraft configure in a way that it detects seamlessly heimdal on Debia, RedHat, here and there ... : https://bugzilla.mozilla.org/show_bug.cgi?id=245467 https://bugzilla.mozilla.org/show_bug.cgi?id=286030 https://bugzilla.mozilla.org/show_bug.cgi?id=245936 https://bugzilla.mozilla.org/show_bug.cgi?id=277882 Per note on Debian. Who said it works seamlessly? I used to use heimdal few years ago and they broke heimdal into several packages, their cross-deps were broken and it was just easier to run configure yourself, get it in /usr/heimdal and than you were ready to report bugs on mozilla, openssh. But at least, you could say you use the standard and you had not to discuss where are your libs, headers and think of name colisions. And there were such problems. Are you aware of these? Look, I don't use kth-krb nor heimdal from Gentoo, so think twice of the output below. # find . -type f | while read file; do if test -a /usr/include/$file; then ls -la /usr/include/$file; ls -la /usr/heimdal/include/$file; fi; done -rw-r--r-- 1 root root 3127 Jul 1 19:56 /usr/include/./ss/ss.h -rw-r--r-- 1 root root 2259 Jul 26 22:03 /usr/heimdal/include/./ss/ss.h -rw-r--r-- 1 root root 2530 Jul 3 02:48 /usr/include/./fnmatch.h -rw-r--r-- 1 root root 2191 Jul 26 22:03 /usr/heimdal/include/./fnmatch.h -rw-r--r-- 1 root root 6970 Jul 3 02:48 /usr/include/./glob.h -rw-r--r-- 1 root root 3803 Jul 26 22:03 /usr/heimdal/include/./glob.h # cd /usr/heimdal/lib # find . -type f | while read file; do if test -a /usr/lib/$file; then ls -la /usr/lib/$file; ls -la /usr/heimdal/lib/$file; fi; done -rw-r--r-- 1 root root 30194 Jul 1 19:56 /usr/lib/./libss.a -rw-r--r-- 1 root root 48394 Jul 26 22:03 /usr/heimdal/lib/./libss.a # BTW, similarly on the kth-krb topic ... # cd /usr/athena/include # find . -type f | while read file; do if test -a /usr/include/$file; then ls -la /usr/include/$file; ls -la /usr/athena/include/$file; fi; done -rw-r--r-- 1 root root 3127 Jul 1 19:56 /usr/include/./ss/ss.h -rw-r--r-- 1 root root 2259 Jul 26 00:36 /usr/athena/include/./ss/ss.h -rw-r--r-- 1 root root 6970 Jul 3 02:48 /usr/include/./glob.h -rw-r--r-- 1 root root 3876 Jul 26 00:36 /usr/athena/include/./glob.h lrwxrwxrwx 1 root root 12 Jul 1 19:55 /usr/include/./com_err.h -> et/com_err.h -rw-r--r-- 1 root root 2502 Jul 26 00:36 /usr/athena/include/./com_err.h # cd /usr/athena/lib # find . -type f | while read file; do if test -a /usr/lib/$file; then ls -la /usr/lib/$file; ls -la /usr/athena/lib/$file; fi; done -rw-r--r-- 1 root root 30194 Jul 1 19:56 /usr/lib/./libss.a -rw-r--r-- 1 root root 48562 Jul 26 00:36 /usr/athena/lib/./libss.a -rw-r--r-- 1 root root 7524 Jul 1 19:55 /usr/lib/./libcom_err.a -rw-r--r-- 1 root root 13688 Jul 26 00:36 /usr/athena/lib/./libcom_err.a -rw-r--r-- 1 root root 67124 Jan 7 2005 /usr/lib/./libacl.a -rw-r--r-- 1 root root 16204 Jul 26 00:36 /usr/athena/lib/./libacl.a -rw-r--r-- 1 root root 789 Jan 7 2005 /usr/lib/./libacl.la -rwxr-xr-x 1 root root 695 Jul 26 00:36 /usr/athena/lib/./libacl.la # If you are still not convinced, this will put a great burden on you and on other developers in the world, imagine openssh people?: http://bugzilla.mindrot.org/show_bug.cgi?id=635 http://bugzilla.mindrot.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=kerberos Actualy my own former experience and more importantly, a message for you that with heimdal-0.7 you must DEPEND on kth-krb-1.3 !!!: http://www.stacken.kth.se/lists/heimdal-discuss/2003-09/msg00014.html And two years later people hit the timebomb (while some are not aware of it even yet ;))): http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00001.html http://www.stacken.kth.se/lists/heimdal-discuss/2003-09/msg00019.html Hard life: http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00044.html http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00014.html http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00017.html http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00022.html Well in general, you have been warned. And last, why didn't you report the patches back to heimdal developers? I had to report similar problem like 011_all_heimdal-kdc_fix.patch, but the patch I got was different (got it today)? Did you discuss your relocate heimdal intent with them actually? I've emailed Love H
I'm reopening the bug because: 1. the ebuild should depend on kth-krb-1.3 if krb4 is to be compiled in. There is only 1.3_rc1 snapshot on the KTH ftp site, but that's what I use and is ok. Explanation _why_ is a bit beyond this discussion, but as I have assemled now a _NOT_EVEN_YET_COMPLETELE_ :-) list of just heimdalrelated bugreports around in of those threads is explained by hard learning why openssl-0.9.7 and kth-krb-1.3 and heimdal-0.7 ... Not everything is a history and obsolete these days, at least that's my impression. You should also learn from those lessons how people struggled the bugs ... 2. Why do you create the soflinks for headers when you claim you can either explain to all other packages that --with-heimdal-headers=/usr/include/heimdal -with-heimdal-libs=/usr/lib ???. This will only cause confusion.: dosym heimdal/krb5-types.h /usr/include/krb5-types.h ... More on the --prefix discussion: You have to have plenty of time the for fixing other configure definitions first. I mean this should happen _BEFORE_ you install into non-standard place. ;) Just look at these bugs and keep in mind _some_ of them are caused just by people getting tired to handcraft configure in a way that it detects seamlessly heimdal on Debia, RedHat, here and there ... : https://bugzilla.mozilla.org/show_bug.cgi?id=245467 https://bugzilla.mozilla.org/show_bug.cgi?id=286030 https://bugzilla.mozilla.org/show_bug.cgi?id=245936 https://bugzilla.mozilla.org/show_bug.cgi?id=277882 Per note on Debian. Who said it works seamlessly? I used to use heimdal few years ago and they broke heimdal into several packages, their cross-deps were broken and it was just easier to run configure yourself, get it in /usr/heimdal and than you were ready to report bugs on mozilla, openssh. But at least, you could say you use the standard and you had not to discuss where are your libs, headers and think of name colisions. And there were such problems. Are you aware of these? Look, I don't use kth-krb nor heimdal from Gentoo, so think twice of the output below. # find . -type f | while read file; do if test -a /usr/include/$file; then ls -la /usr/include/$file; ls -la /usr/heimdal/include/$file; fi; done -rw-r--r-- 1 root root 3127 Jul 1 19:56 /usr/include/./ss/ss.h -rw-r--r-- 1 root root 2259 Jul 26 22:03 /usr/heimdal/include/./ss/ss.h -rw-r--r-- 1 root root 2530 Jul 3 02:48 /usr/include/./fnmatch.h -rw-r--r-- 1 root root 2191 Jul 26 22:03 /usr/heimdal/include/./fnmatch.h -rw-r--r-- 1 root root 6970 Jul 3 02:48 /usr/include/./glob.h -rw-r--r-- 1 root root 3803 Jul 26 22:03 /usr/heimdal/include/./glob.h # cd /usr/heimdal/lib # find . -type f | while read file; do if test -a /usr/lib/$file; then ls -la /usr/lib/$file; ls -la /usr/heimdal/lib/$file; fi; done -rw-r--r-- 1 root root 30194 Jul 1 19:56 /usr/lib/./libss.a -rw-r--r-- 1 root root 48394 Jul 26 22:03 /usr/heimdal/lib/./libss.a # BTW, similarly on the kth-krb topic ... # cd /usr/athena/include # find . -type f | while read file; do if test -a /usr/include/$file; then ls -la /usr/include/$file; ls -la /usr/athena/include/$file; fi; done -rw-r--r-- 1 root root 3127 Jul 1 19:56 /usr/include/./ss/ss.h -rw-r--r-- 1 root root 2259 Jul 26 00:36 /usr/athena/include/./ss/ss.h -rw-r--r-- 1 root root 6970 Jul 3 02:48 /usr/include/./glob.h -rw-r--r-- 1 root root 3876 Jul 26 00:36 /usr/athena/include/./glob.h lrwxrwxrwx 1 root root 12 Jul 1 19:55 /usr/include/./com_err.h -> et/com_err.h -rw-r--r-- 1 root root 2502 Jul 26 00:36 /usr/athena/include/./com_err.h # cd /usr/athena/lib # find . -type f | while read file; do if test -a /usr/lib/$file; then ls -la /usr/lib/$file; ls -la /usr/athena/lib/$file; fi; done -rw-r--r-- 1 root root 30194 Jul 1 19:56 /usr/lib/./libss.a -rw-r--r-- 1 root root 48562 Jul 26 00:36 /usr/athena/lib/./libss.a -rw-r--r-- 1 root root 7524 Jul 1 19:55 /usr/lib/./libcom_err.a -rw-r--r-- 1 root root 13688 Jul 26 00:36 /usr/athena/lib/./libcom_err.a -rw-r--r-- 1 root root 67124 Jan 7 2005 /usr/lib/./libacl.a -rw-r--r-- 1 root root 16204 Jul 26 00:36 /usr/athena/lib/./libacl.a -rw-r--r-- 1 root root 789 Jan 7 2005 /usr/lib/./libacl.la -rwxr-xr-x 1 root root 695 Jul 26 00:36 /usr/athena/lib/./libacl.la # If you are still not convinced, this will put a great burden on you and on other developers in the world, imagine openssh people?: http://bugzilla.mindrot.org/show_bug.cgi?id=635 http://bugzilla.mindrot.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=kerberos Actualy my own former experience and more importantly, a message for you that with heimdal-0.7 you must DEPEND on kth-krb-1.3 !!!: http://www.stacken.kth.se/lists/heimdal-discuss/2003-09/msg00014.html And two years later people hit the timebomb (while some are not aware of it even yet ;))): http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00001.html http://www.stacken.kth.se/lists/heimdal-discuss/2003-09/msg00019.html Hard life: http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00044.html http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00014.html http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00017.html http://www.stacken.kth.se/lists/heimdal-discuss/2005-07/msg00022.html Well in general, you have been warned. And last, why didn't you report the patches back to heimdal developers? I had to report similar problem like 011_all_heimdal-kdc_fix.patch, but the patch I got was different (got it today)? Did you discuss your relocate heimdal intent with them actually? I've emailed Love Hörnquist Åstrand as I said, and this is is his answer when I pointed him to this bugreport telling about these patches: <quote> No, I didn't know about that, I'll look them over. The patch you tried will be part of 0.7.1. </quote>
Previous comment is true except the faxct I'm not allowed to reopen. ;)
ok, to respond to you quickly : 1. I do intend to share these patches with heimdal's upstream. It's been a matter of testing and time 2. the symlinks we create are *NOT* /usr/heimdal-> at all!! They are /usr/include/heimdal -> /usr/include/gssapi, nothing more. 3. I would really like for mit-krb5 and heimdal (and shishi if applicable) to get their respective acts together and install into standard locations, instead of locations that they just make up (like /usr/heimdal). Besides any of that, nothing in gentoo breaks because of heimdal not being in /usr/heimdal, that I know of. If there are, please show them to me, because I'd like to fix things :)
1) you have not fixed the dependency on kth-krb-1.3 2) how do you protect from overwriting those headers and libs I have shown that do exist in /usr/heimdal and /usr? 3) tell me how are you going to support simultaneous installation of heimdal and kth-krb, it is needed when people want krb4 backwards compatibility, for whatever reason. You install both into /usr?
as this is a bug not a discussion forum, it would be good idea to file the kth-krb-1.3 issue as a *separate* bug. In gentoo, /usr/heimdal does not exist, period. If it does, it's not because of ebuilds. I haven't looked at krb4 yet, but we'll find a way to support simultaneous installs. I would prefer you do this: 1. file a *new* bug for kth-krb-1.3 2. File a *new* bug for discussing fhs vs. heimdal install locations.
