David Holland <dholland-pkgtech%netbsd.org@localhost> writes: > On Sat, Apr 30, 2022 at 07:44:34PM -0400, Greg Troxel wrote: > > In the curl case, I don't see the bloat as really terrible, in terms of > > effective bloat. Tons of things need gmake, so any bulk build is going > > to need it. So basically that doesn't count. And really, same with > > python, except for a system that is not doing much. > > The practical problem (or one, anyway) is that cmake depends on curl, > and curl depends on Python, so any in-place live rebuild (e.g. with > pkg_rr) will need to rebuild Python early and this can considerably > increase the time during which Python stuff is bust. It also makes it > a lot harder to do incremental live rebuilds of one disjoint chunk of > packages at a time (granted, I don't think pkg_rr readily supports > this...) 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. 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. > Of the extra deps, only libxml2 is large/slow, and it doesn't change > often, so it seems like a minor annoyance unless you somehow don't > need to have it installed; but that seems unlikely; for me it has 1-2 > dozen things things depending on it, some of which are pretty hard to > avoid incurring (e.g. py-lxml, libxslt, xmlto). > > I find the ordering issue annoying, but the build time argument seems > somewhat dubious. I have also set DEPENDS_TARGET="bin-install clean", so even if I 'pkgin ar', then if something is needed at build time, and it hasn't had a revbump, it is just installed. So far that's been a good plan.
Attachment:
signature.asc
Description: PGP signature