John Klos <john%ziaspace.com@localhost> writes: > We have packages like www/curl that have default options that > significantly increase compile time. For example, compiling with http2 > requires all these additional packages: > > gmake > libffi > libuuid > libxml2 > nghttp2 > python310 > readline > xmlcatmgr > > On a fast machine, total CPU time goes from 120 seconds for building > just curl to 640 seconds for all of the extra dependencies plus curl, > which is a significant difference. > > Whether http2 is really ever needed is not what I want to discuss > here, but we can see that having a common tool and common dependency > like curl without all the extra fluff may be desirable. I choose to > exclude http2 in general. In an ideal world (which is not the world in which we live in, even before we mention the r-word), this would be a plugin and curl would not depend on that long list, curl-http2 would, and curl would autodetect and load the http2 module, so people who need it can install curl-http2, and people don't can refrain from installing it. But for many packages, whether to add feature foo at cost of bloat X is a build-time choice. > However, I've noted that rust fails to build when curl is built with > -http2, as seen in PR#56786: > > https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=56786 > > This leads me to wonder about a few things: > > 1) Forgetting for the moment that Rust should be using its own > internal curl, in general, how should a package handle the requirement > for specific options in packages it requires? There is no good way, because it might be installed, and it's not really reasonable to say "if options of dependency A don't match what I want, do make replace with my options". And it's not ok for pkgsrc to end up in different states based on order of builds, except we allow "I want pgsql" to be "if the installed version is acceptable use it", so people who build a non-default pgsql first end up using that for everything. As an alternative we could make them set the default version, but it wouldn't really buy much. > 3) In cases where default options bring in significant dependencies, > should we default to lighter instead of heavier? For instance, > liblinear used to be enabled by default for net/nmap which used to > bring in a whole additional gcc. How should decisions like these be > made? Generally, we try to minimize total pain across pkgsrc users. If a lot of people want a feature, and it doesn't hurt much, we include it. That has bloat for those who don't, and those who do can use the binary package. If we leave it out, then the non-users are spared the bloat and the users have to build from source. For nmap, my view, not backed by data, is that lots of people want to "nmaps -sP" occasionally to see what's up on their network etc. but not that many want the complicated stuff you need liblinear for. So off seems right. Basically it's all difficult case-by-case discussions. 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. So the questions are: averaged over real systems where builds are done, which packages need to be built in a pbulk that builds an actual set of needed packages with curl using nghttp2, but are not needed with curl not using nghttp2 averaged over real systems, which packages need to be installed with curl using nghttp2, that would not be if curl were not I really mean over real systems, with an actual package list somebody uses, not a "but if I just install curl I get X, Y and Z extra". With nmap, I could not build it on a RPI3, but with liblinear turned off, it built easily. That same system has curl and I was never aware of this.
Attachment:
signature.asc
Description: PGP signature