--On Wednesday, May 28, 2003 10:19 AM -0400 Alan DeKok <[EMAIL PROTECTED]> wrote:
Owen DeLong <[EMAIL PROTECTED]> wrote:I'll agree with that to some extent. However, I should be able to say "This package is available and it's PREFIX is XYZ" somehow to solve this. That works with almost every other package I've built using autoconf's configure.
We welcome patches to the 'configure.in' files. The only issue is that there is a 'configure.in' file in each module directory, so each of those files must be patched.
If I had the expertise to produce them, I would do so. However, I'm a network architecht, not a software developer. The whole process of AutoConf is a black box to me. Using it's output sometimes baffles me. Modifying it's input is beyond my current skills.
> The response then, as now, is "don't do that." > Yeah... That's nice. Given a choice, I wouldn't. However, I have to work in an existing environment where I can't dictate policy to the other people who run this stuff. They're managing a few hundred packages across a few thousand machines. Since I don't want to try and replace their entire group with my own opinion of how things should be to build one package, I kind of need to find an alternative.
I understand. What surprises me is that there are *other* networks which manage hundreds of packages across thousands of machines, and they haven't seen the need to screw up the packaging that badly.
Well, it's more complicated than that, and, my statements of what was going on were an oversimplification. The package management system they have developed has kind of evolved over the years and provides some pretty nifty capabilities (like the ability to restore any server in the network by applying about 30 minutes worth of changes to the base template which is stored on _ALL_ "spares" and a quick restore of any machine-specific variable data [in this environment, that's rare]).
The ability to have multiple instances (versions) of any package on the machine. Centralized knowledge of what packages/instances are installed on what machines, etc. For what they usually do, it's quite useful. For certain circumstances, it's limitations are frustrating.
> So you have multiple options to get FreeRADIUS working on your > system, and none involve patches or changes to FreeRADIUS. > I didn't figure they would. I offered to provide DIFF's to the INSTALL document documenting the applicable solution for other users.
If you want to change the options to 'configure', then that would be the best way of solving the problem for everyone.
Yeah... if I knew how to do that, I'd agree with you. FWIW, I looked at configure.in, and, it scared me. :-) I undertsand the Cyrillic alphabet, but I haven't mastered the greek one. (ok, maybe that was too abstract a pun)
Another thing I noticed, however, was that FreeRadius seems to be OK linking against SASL2, but, won't detect SASL with the SASL2 libraries installed. I haven't tested whether it runs correctly or not yet. I had to manually modify a bunch of things to get it to look for the -lsasl2 instead of -lsasl. Seems to me that the SASL detector should be modified to look for -lsasl2, and, failing that, -lsasl.
Owen
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
