> From: Nick Davis
> Sent: Wednesday, 1 October 2003 3:34 AM

> > > 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!

Beats me. We can hope, I guess. :-) You might find that building on unstable
is also viable right now, testing's fairly up to date.

> > > 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 

Huh? It should... That's _why_ IODBC's the prime candidate, since the _other_
databases that are built are split out already.

> 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. 

The other candidates are rlm_unix (for shadow group membership) and...
I dunno. I'm sure I had others, but I can't for the life of me remember.
Unixodbc was discussed, but it's a pain to build since I think iodbc-dev and
unixodbc-dev can't be installed at the same time.

> 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.

Arrgh. It would be the other way 'round, in fact. Headless install should do
just what the user asks. Either way, I think that's abuse of debconf and the
package management system as a whole. I would annoy aptitude users and people
installing with dpkg, off the top of my head.

> 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?

Because it splits out the resulting package, but it still builds those
modules....

Aaah! Now your earlier comment makes sense. What we're doing here is
splitting the resulting package files so that the target server doesn't
gain library dependancies which are unnecessary for that installation.

It still _builds_ all the modules. It's just when it assembles the
modules into packages that the list matters.

> > libkrb5-dev is for rlm_krb5
> >
> > None of these build-dependancies are for the core daemon.

I left off dependancies on openssl-dev, which are liberally spread
amongst the server. (Easy enough to find, I hope. :-)

The following instructions are how to remove build-dependancies.

If you want an example, have a look at http://www.tbble.com/freeradius/
which is my DFSG-free FreeRADIUS build sans EAP/TLS, rlm_x99_token, and
rlm_sql_postgresql (at least...) so it's a good example of dropping
build-depends for all the types of modules. :-) (Have a look at the .diff
file, it's against 0.9.1.)

> > 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.

Yeah. That's why my production box has -dev packages up the wahoo, and is
in fact the main reason behind my thrust to get it into Debian proper...
I got fed up compiling it myself... Months later, and I'm a FreeRADIUS developer
and compiling two or three times a week in a quiet month. :-)

--
Paul "TBBle" Hampson
Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

On a sidewalk near Portland State
University someone wrote `Trust Jesus', and
someone else wrote `But Cut the Cards'.


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to