tech-pkg archive

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

the path to USE_CWRAPPERS=yes

Jonathan Perkin <> writes:

> * On 2016-02-18 at 12:34 GMT, Greg Troxel wrote:
>> Jonathan Perkin <> writes:
>> >> [1] What's keeping this, anyway?
>> >
>> > I don't know but I'd like to see it happen 12 months ago.  The
>> > difference in reduced build/system time is astonishing and I've used
>> > it for all my builds for a long time now.
>> Perhaps you could start a new thread with the accumulated evidence that
>> enabling cwrappers does no harm, in terms of missing packages in bulk
>> builds, and packages that can't be build normally, on various platforms.
>> Because I haven't seen a "here is the data; I think we're over the bar",
>> I have been under the impression that we hadn't yet arrived at time to
>> flip the default.
> This really needs to be done on NetBSD, as the only platform which can
> currently build almost all of pkgsrc.  I don't have any NetBSD bulk
> build infrastructure, so this will need to come from someone else.
> However, for the bulk builds I perform on SmartOS, OSX and Linux, I'm
> not aware of any regressions caused by moving to cwrappers, just
> significantly faster builds.

Not a bulk build, but on a netbsd-7 amd64 machine, I

  update pkgsrc to HEAD
  rebuilt everything needing it with pkg_rr
  did not change pkgsrc
  make replace on something random
  pkg_admin rebuild=yes \*

and that resulted in 762 packages being rebuilt, plus the cwrappers
The only issue is glusterfs, but so far it looks like that did not build
the first time and isn't a cwrappers issue.

I also did the same thing on netbsd-7 i386, but with 595 packages.

Admittedly this is a fractional sample, but things look good from my

Is anyone seeing anything broken with cwrappers?

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index