Hi all,
In message <[EMAIL PROTECTED]>, Alan DeKok
<[EMAIL PROTECTED]> writes
David Wood wrote:
I am about to start working on an update of that port to 2.0.0 - and it
will likely be renamed net/freeradius2 at the same time, as it's no
longer a development version. My part of this isn't likely to take too
long (hopefully <12 hours to submit the FreeBSD PR barring unexpected
problems as I start to work on it this evening), but getting it
committed to the FreeBSD ports tree will take longer.
Sounds good to me.
I was a little bit slower than I'd hoped, but I've now submitted FreeBSD
PR ports/119582 to create the net/freeradius2 port (and get rid of the
net/freeradius-devel port which was pretty much stillborn this time
round).
The PR can be viewed at:
http://www.freebsd.org/cgi/query-pr.cgi?pr=119582
If you want a copy of the port now, make a copy of an up to date (that's
important!) /usr/ports/net/freeradius outside /usr/ports, apply the
patch in the PR to your copy, uninstall your current FreeRADIUS (follow
the advice in the suggested entry for /usr/ports/UPDATING please), then
'make config clean install' should give you a working FreeRADIUS 2.0.0.
Whilst this may not be exactly the form that the port is committed as,
it is working fine on my system.
PATCH SUBMISSION - THREADING ISSUES
I'd be grateful if someone from the FreeRADIUS team could look over
files/patch-pthread for inclusion in FreeRADIUS itself.
<http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/freeradius-devel/files/p
atch-pthread?rev=1.1> is a version of the patch that should apply
cleanly against 2.0.0. If you want a 1.1.7 version, look at the same
file in freeradius rather than freeradius-devel. It would be useful if
both 1.1 and 2.0 could be patched in this way.
The patch solves two problems.
Firstly, for threading on FreeBSD you should just use -pthread (and not
use -lpthread). There are different threading libraries available on
FreeBSD; the OS does the correct thing if you just use -pthread.
Secondly, it deals with the case where python is built with threads (as
is now the default for python on FreeBSD). As I don't use rlm_python, I
can't test whether it works after this patch, but rlm_python won't even
build on FreeBSD without it.
FREEBSD PORTING ISSUES FOR 2.0.0
When creating the 2.0.0 port, I made a couple of decisions that may be
unpopular amongst embedded system users.
Firstly, NOPERL is now only available as a knob, and has been removed
from the options. It was a horrid hack as I've explained in some new
Makefile comments. If you really need it use make -DWITH_NOPERL - but
building FreeRADIUS without perl available is not recommended.
I've also chosen to depend unconditionally on python for 2.0.0, and
always build rlm_python. Of course, I could configure
--without-rlm_python. The problem is that, at the moment, the FreeBSD
ports system doesn't allow a conditional dependency on python without
the nasty hack previously used when the experimental option was
selected. The hack causes portlint to declare the port has a FATAL
error, and I didn't think I'd get away with moving it elsewhere in the
Makefile.
bsd.options.mk will solve this problem. When it's available, ports will
be allowed to act on their options before including any of the
bsd.port.mk stuff, which means all USE options can be conditional on
options.
Unfortunately, bsd.options.mk can't be used yet as the necessary OS
support only exists in the as yet unreleased FreeBSD versions 6.3 and
7.0. At minimum I think it will need passing the End of Life date of the
entire 5.x branch and the subsequent ending of ports support for 5.x, as
well as passing the End of Life date for 6.2 before ports are allowed to
use bsd.options.mk. This could all happen on or shortly after 31 May
2008.
Porting is a bit of a nightmare at the moment, as you have to support
5.x, 6.x, 7.x and the development 8.x tree. There are no plans for
another 5.x release, and I'm one of those that was no great fan of 5.x.
Anyone who has a machine running any version of FreeBSD earlier than 6.x
is encouraged to consider an upgrade to 7.0-RELEASE when that is
available, hopefully within the next two months. If 7.0-RELEASE is too
bleeding edge for you, try 6.3-RELEASE (also currently in RC) instead.
I could be persuaded to revisit the NOPERL stuff, though I can only
really see two ways to do this properly. One is a conditional patch
configure.in to disable all the perl tests, which is a maintenance
nightmare for me. The other is to persuade the FreeRADIUS developers
included a configure flag to disable perl globally.
The final option was to go back to the messy 1.x situation; my reading
of the configure.in is that the absence of perl merely generates a
warning and that disabling rlm_perl is enough.
There is the risk of strange brokenness in following the messy route if
FreeRADIUS's dependency on perl ever changes; most desktop and server
FreeBSD installations do have perl installed, and it will be available a
lot of the time when a FreeRADIUS package is built, so configure will
detect perl. If that package is then installed onto a system without
perl, is it guaranteed to work properly?
As I've explained, my hands are rather tied over Python at the moment.
If the inclusion of Python causes real problems for embedded users,
maybe the answer for now is a slave freeradius2-without-python port. I
don't want to go down that route unless I really have to, however.
Best wishes,
David
--
David Wood
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
