pkgsrc-Changes archive

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

Re: CVS commit: pkgsrc/pkgtools/pkg_rolling-replace

2010/2/1 Greg Troxel <>:
>  > I also don't understand the -j option.  While I want pkg_rr to "just
>  > work", I also leave PKG_DEVELOPER=YES and MAKE_JOBS=2 in mk.conf so I
>  > can fix/notice underlying package problems.
>  But I don't want MAKE_JOBS=2 being always active. E.g. when updating a
>  package (let's name it math/pari) and want to see the compile errors.
> So you want to set MAKE_JOBS=2 when doing testing of packages, but turn
> it off when doing rebuilds?
> I wonder if having pkg_rr define some sort of variable to indicate that
> we're in a bulk update or pkg_rr mode would help, and then you can put
> in mk.conf the equivalent of:
> if in_pkg_rr
>  blah blah
> fi
> and people can set whatever they want conditionally.

Applied using IN_PKG_ROLLING_REPLACE. Another suggestion may
BATCH_BUILD (which could be set by pkg_chk and pbulk, too).

>  > Then set USE_DESTDIR=no ...
>  I've seen that pkg_rr doesn't transports environment variables to
>  ${MAKE}. And there's a difference for me between developing on pkgsrc
>  and using pkgsrc. During developing, I'm present and act on
>  errors. During using (e.g. update X11 & Co.), I'm not present and
>  simply want it working.
> I can certainly see why you have that as a goal.  I wouldn't object to a
> generic "set this in the make environment" option, but I am wondering if
> my suggestion of a pkg_rr-specific variable always defined would make
> that unnecessary.

tnn@ suggests to allow give several setting to make(1), so I modified -D
to take VARIABLE=VALUE and removed -j.

The attached patch contains the changes. If nothing said against it,
I'd commit it.


Attachment: patch-pkg_rr
Description: Binary data

Home | Main Index | Thread Index | Old Index