Re: Make options revisited

["Carl A. Schmidt" <carl@xxxxxxxxxxxxxxx>]

On Sun, Sep 04, 2005 at 01:46:06PM +0200, Joerg Sonnenberger wrote:
> Please, noone commits this until the various issues are resolved.
> 
> On Sat, Sep 03, 2005 at 08:13:03PM -0400, Carl A. Schmidt wrote:
> > I could see that being a problem for people who are extremely used to
> > that particular convention (NOMAN=noman).
> 
> NOMAN is used by external Makefiles.

Okay.  I see what you mean there.

> > With regards to PPP:
> 
> I'm thinking about just having a single PPP_DISABLE_OPTION knob which
> lists the suboption like
> PPP_DISABLE_OPTION=	suid atm nat
> 
> > With regards to NO_INET6:
> 
> I think it should be scrapped.

Remove NOINET6 altogether?  Hrm, okay.

> > With regards to NO_HTML:
> 
> I have to check, but this can be scrapped too, I think.

Probably, as far as I can tell it disables installation of HTML
documentation in libdialog or something, but that's all.

> > With regards to NO_INFOCOMPRESS:
> >  o This is undocumented and I assume serves the same purpose as
> >    NO_MANCOMPRESS.
> 
> Yes.

Cool, so I can document that.

> > With regards to NO_PAM:
> >  o This pops up in ftpd, lukemftpd, login, and passwd.  Self-
> >    explanitory.
> 
> IMO should be scrapped too.

Probably, I don't know that it's entirely useful because it doesn't
actually disable PAM from being built.

> > With regards to NO_PIC:
> >  o Undocumented, probably better off that way as I doubt too many
> >    people will ever tweak this knob one way or the other.
> 
> This should go away too. No all static configurations please, if someone
> really wants to do that, she can cleanup afterwards.

Okay.

> > With regards to NO_FSCHG:
> >  o Undocumented, possible feature.  I guess someone might find it
> >    necessary to not install certain binaries without the flag fschg.
> 
> It is *very* useful. It allows you "make installworld" in a jail :-)

Didn't know that, but that's cool.  I'll document it.  I guess maybe
that's documented in a jail manpage?

> > The default make.conf file went under the axe the most I'd say because
> > it is ridiculously behind the times, ports or no ports.  I removed all
> > (I think) references to the FreeBSD ports system, as it has been
> > stated that pkgsrc will be officially supported, the rules are a bit
> > different I'd assume.
> 
> I haven't checked it yet, but that's OK with me.
> 
> > All instances of NOSHARED were changes to NO_SHARED, ditto for
> > NOPROFILE.
> 
> No. Just like NOMAN, this knobs are used by external Makefiles.

Hmm, I didn't know that, but okay.  I guess there is a method to
some of the make madness.

> > NOINSTALLLIB was changed to NO_INSTALLLIB (only shows up twice iirc).
> 
> This is fine with me.

Yeah, it only shows up twice, but the more I think about it, it's not
visible to world or anything, as it seems to just be a part of
bsd.lib.mk and probably is just a retarded-ism of myself feeling a
desperate need to do something even remotely useful by changing things
to the one true retard way (NO_OPTION...) when really this would serve
nobody.

I suck. :)

> > I understand that it will possibly be a source of contention, but with
> > the NO_KERBEROS option, kerberos would be built by default.  I don't
> > know how desireable that is, but then why bother having the code at
> > all in the tree if it's not built by default?
> 
> (a) It is not active by default, because most people don't use Kerberos
> for authentication.
> (b) It is in the base system because it adds a lot of problems to add it
> purely from pkgsrc/ports. Keep in mind that any Active Directory Windows
> domain uses Kerberos.
> 
> I don't think the default should be changed.

Hrm, how about changing to WANT_KERBEROS or something, because there is
another option hanging around lukemftpd called WANT_LUKEMFTPD
(undocumented) and that would be nice to at least have that be
consistent?

Well, I have lots of homework to do, hopefully I'll get enough done
that I can start reworking this.  I'll resubmit a new patch hopefully
by the end of the night.
-- 
Carl Schmidt
carl@xxxxxxxxxxxxxxx