pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg/48157: pkgsrc 2013Q2 make-system exeeds max. command line length

The following reply was made to PR pkg/48157; it has been noted by GNATS.

From: Aleksej Saushev <>
Subject: Re: pkg/48157: pkgsrc 2013Q2 make-system exeeds max. command line 
Date: Mon, 16 Dec 2013 13:51:38 +0400

 Wolfgang Stukenbrock <> 
 > Hi to all,
 > I don't think that placing variables only needed for "some"
 > builds - for whatever reasons - in /etc/mk.conf is a real good
 > sollution.
 > This special variable is used to suppress lots of messages while
 > building some packages during "initial" system installation -
 > the state of the network is unknown at this time.
 > (We've automated the system setup a little bit, because it is
 > not practical to setup (or upgrade) many systems by hand in a
 > consistant way.)
 > The variable should not be setup for builds later if the system
 > is completely configured and running.
 > And I also don't think that editing in /etc/mk.conf "all the
 > time" is a good idea either.
 > /etc/mk.conf is the right place to setup system depedant things
 > - e.g. support for the different compilers on a Solaris system -
 > or "security"-setups like to disallow automatich installation
 > into /etc/shells.
 > But neverless, it is no good idea to replicate command line
 > options while calling make in a recursive way. And this is done!
 > You will loose even without setting some additional things on
 > the command line if the recursion is deep enought.
 > So I don't think to solve this issue is "to hack around for a
 > special usage" as mentioned in an other reply before.
 > And I also don't thing that specifying variables with "-D .." is
 > an unexpected usage. E.g. the messages when additional licenses
 > are needed to be accepted suggest to do this.
 I'm of exactly the opposite opinion. It makes maintainance a lot easier
 when all settings are recorded. mk.conf is the place where such settings
 are kept in pkgsrc, thus "editing all the time" is the way to operate
 pkgsrc installation. I'm not sure that providing hacks that work around
 this requirement does any good. It can work for people with high
 organisational skills like old-school researchers and engineers who
 follow the old tradition of "everything must be written down in the
 laboratory log," but we have too few of them these days.
 In my opinion, in your particular case it would be better to skip
 vulnerability check for particular set of packages. E.g.:
 .if ${.CURDIR:M*/www/firefox}
 .if ${.CURDIR:M*/multimedia/mplayer}
 HE CE3OH...

Home | Main Index | Thread Index | Old Index