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