tech-pkg archive

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

Re: pkgsrc leakage and default pkg options



On Wed, May 04, 2022 at 08:09:21PM -0400, Greg Troxel wrote:
 > Indeed, there is no support in pkg_rr for graph partitioning.
 > 
 > But I don't follow "rebuild Python early ... increase the time during
 > which Pytthon stuff is bust".  Yes, if python 3.9.x has gone to x++, or
 > has a nbN++, then it will get "make replace", but almost always there is
 > no ABI change, so the breakage is limited to the "pkg_add -u -U" call
 > which is a few seconds.

I was under the impression that in such a case, until you rebuilt all
your Python extensions they'd be in the wrong subdir and not findable.
But maybe that's not true any more? (Or maybe it was never true and I
was confusing it with Perl or something else...)

 > As I see it, the real problem is that cmake is a common build tool and
 > cmake is enormous with lots of dependencies.  At least it isn't written
 > in rust.

Don't give them ideas :-)

 > > Of the extra deps, only libxml2 is large/slow, and it doesn't change

That meant "besides Python", which isn't super-fast. On the other
hand, these days it's really hard to not need Python installed, so
you're almost certainly paying that cost regardless.

Also, I guess there's an elapsed-build-time argument if you're doing
builds to setting up a VM image, but in that case ISTM that you should
be doing something that caches the images so it doesn't happen often
enough to matter much.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index