> > I have been using freeradius since 0.3 installed from source and I wanted > > to give the debian package a try. I did not see a freeradius package in > > unstable nor testing. Is freeradius still changing too fast for debian? > > Not anymore, I feel. The prospective Debian packaging of 0.9.1 is with the > prospective sponsor, so hopefully in time for Sarge's release...
Lets hope so! I'll just have to get my own .deb package to build for now then. > > I am building the debian package on a debian Woody stable system and am > > going to copy it over to a debian Sarge testing system. > > Wild. Any reason you're not building it on a testing system? I'd offer to > do so, but my testing machine is also PowerPC, and so the packages probably > aren't a lot of use to you. :-) I only have one system running testing and that is already setup to be a production server. I do not want to install any *dev or compiling packages on there. I figured that it would work fine if I build the packages on Woody and then installed them on Sarge. Sarge should have all of the required packages, but newer versions. So, it should still work. If I'm wrong on that assumption, please let me know! > > I found the instructions Paul H. wrote below along with his other post > > that has the patch to take iodbc out of the main freeradius package. I > > applied that patch with little trouble, and am now to the instructions in > > the email below. > > I'm still fielding good reasons to include that patch in the main package. > :-) There're concerns about package-list-bloat, and I've yet to come up > with a convincing argument that overrides that. I noticed while applying the patch was that it split iodbc out into it's own package, but didn't split out postgres, mysql, and ldap. If you are going to split out one, you should split them all (or at least most) out of the main package. Yes, I know that patch was only to split out iodbc, I'm just saying we should do an all or none scheme. A good way to do that would be to ask this question "Is there more than one module that does a similar job as this module I am looking at?" If yes, split out those modules into their own packages. If not, leave it as part of the main package. So, if you were looking at mysql, you would answer yes. Then you would split out mysql, postgresql, iodbc, and whatever other database modules there are. If you look at other server software that has a whole slew of modules, you will see many modules are broken out into their own packages. Examples: apache, php, mysql, postfix, perl So, lets add freeradius to that list. It will make the base package simpler. So, when a person wants to use a module they just grab the package containing said module. Here is another thought: If you break out the modules into separate packages, on installation of the main package you could present the user with a short menu to select which modules they would like to install. If they are installing in the debian mode where it doesn't ask the user for any input, just assume they selected all of them. My $0.02 towards that argument:) > > Here is the list I get: > > dpkg-checkbuilddeps: Unmet build dependencies: libltdl3-dev, > > libpam0g-dev, postgresql-dev, libgdbm-dev | libgdbmg1-dev, libldap2-dev, > > libsasl2-dev, libiodbc2-dev, libkrb5-dev > > > > I do not plan to use kerberos, ldap,nor postgres and I'm not so sure that > > I need libgdmg1 either. I use mysql for everything except the > > dictionaries. > > > > My question is: how can I remove some of the build dependencies for > > packages that I do not intent to use? > > libpam0g-dev is used by rlm_pam > > libgbmg1 is used by rlm_counter, rlm_gdbm and rlm_ippool > > postgresql-dev is for rlm_sql_postgresql > > libldap2-dev and libsasl2-dev are for rlm_ldap > > libiodbc2-dev is for rlm_sql_iodbc Why would this still be here if I already applied the iodbc patch? > libkrb5-dev is for rlm_krb5 > > None of these build-dependancies are for the core daemon. > > The way I'd do it is remove those modules from the 'stable' file in > src/modules or src/modules/rlm_sql/ depending on which modules they are. > This step is basically optional, since it should skip that which it can't > build. > > Then remove the entries for those things from debian/rules in the various > 'for each' clauses. And remove the entries from the debian/control file. > (ie. the opposite of the freeradius-iodbc patch you've already got. :-) > > Then remove the build-dependancies that trouble you so. Wow, what a pain in my behind! I can't wait for prebuilt debian packages. > You'll need that libltdl3-dev, however. No way around it except building > statically, and I dunno what that does to the build-dependancies, or the > rlm_sql and rlm_eap modules. Good to know thanks! Nick -- Nick Davis Associate Systems Administrator [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 Web Development-Web Marketing-ISP Services - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
