Date: Fri, 31 Jul 2009 12:55:18 +0000 From: "b. f." <bf1783@googlemail.com> To: freebsd-ports@FreeBSD.org Cc: Peggy Wilkins <enlil65@gmail.com> Subject: Re: Using WITH_OPENSSL_PORT Message-ID: <d873d5be0907310555n6a660a49x53e287ee05b8fec0@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Peggy Wilkins wrote: ... >It turns out there are a number of open PR's for related issues. For instance: > >ports/120101: security/krb5 utilities link against wrong libcom_err >http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/120101 > >ports/121573: security/krb5 (MIT Kerberos) generates non-working ksu >http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/121573 > >ports/128972: Port security/krb5 has a linking problem when compiled >against base openssl >http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128972 >I get a working security/krb5 compiled against base openssl, if I >preface all the client commands with LD_LIBRARY_PATH=/usr/local/lib. >I'm not sure what a good resolution for all those PR's would be... how >is this sort of conflict of shlibs normally resolved for ports? I don't see why it is necessary to engage in all these gymnastics: it seems to me that the krb5 port should be able to coexist with the base system Heimdal if the proper environment variables (KRB5_HOME, HEIMDAL_HOME, etc.) are set during the build and at runtime. Maybe you should take a look at whether you've done so, and if it still doesn't work, talk to the maintainer about cleaning up the port. It sounds as if it needs some work. >Another thing that occurred to me (I may have seen it online >somewhere) is that if I replace the base kerberos with ports/krb5 >compiled against the base openssl, my problem with multiple >conflicting shared libraries would go away. It looks like I can build >my system with WITHOUT_KERBEROS setting in /etc/src.conf, though I am >still unsure how to remove the already-installed kerberos on my >production system -- do I hunt down and delete the already-installed >files, or is there an easier way to do that? >BTW even though I've been running FreeBSD for over 6 years now, I >hadn't heard of /etc/src.conf before this weekend. How do people find >out about that? I'm surprised to have missed it before now. If you are convinced that the base system Kerberos is unsuitable for your purposes, then I see no reason why you should build and install it. Caveats: you will lose Kerberos support in several base system utilities like ssh, cvs, telnet, etc. So if you want this, you will have to replace them with other software, or patch the base system build infrastructure. If the repository commit history is to be believed, src.conf first made it's appearance early in 2006, before the release of FreeBSD 7. Before then, the base-system build knobs were used in make.conf. Some of the knobs, or their equivalents, have been around for quite a long time. Cf. http://svn.freebsd.org/viewvc/base/head/share/examples/etc/make.conf?view=log I suppose that if you had not been following the course of development, and if it was not in the release notes for 7.0, then you probably would have noticed the advent of src.conf(5) by noticing that it was referenced in build(7) or make.conf(5). If the knob is set up properly, then running 'make delete-old' will remove the files that are no longer installed as a result of the knob. Unfortunately, some of these knobs receive little testing and maintenance, so some of them break the build(WITHOUT_KERBEROS + WITH_GSSAPI, or WITHOUT_NETGRAPH, for example), and others leave files behind. So I recommend looking for files or directories in the base system that weren't modified by an installworld + installkernel, and not removed by make delete-old. You could use some variation on: find / ! \( -path '/home*' -or -path '/usr/local*' -or -path '/etc*' -or -path '/root*' -or -path '/tmp*' -or -path '/usr/src*' -or -path '/usr/doc*' -or -path '/usr/tmp*' -or -path '/var*' -or -path '/usr/ports*' -or -path '*.snap' \) -and ! -ctime 1h Then determine whether they should be deleted by inspection. I wouldn't do this automatically (at least at first, until you've had a chance to debug your check), as a handful of ports ( perl5, etc. ) place files or links in the base system that should not be removed, and you may have local modifications. mergemaster(8)'s diagnostic messages should help you determine which files in /etc are no longer needed. b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d873d5be0907310555n6a660a49x53e287ee05b8fec0>