John Klos <john%ziaspace.com@localhost> writes: > Quoting myself: > >> Why does nmap use pkgsrc lua on NetBSD when NetBSD has lua by default? > > I should clarify. I think it'd be worthwhile to have a discussion > about how what's included in base affects decisions about pkgsrc. For pkgsrc, there are N versions of "base", for some very large N. Between operating systems and versions, N is probably at least 50. It is possible to add builtin support to lua to have it use base lua if it's good enough. I think it's just that nobody has done that yet. In the case of lua53, I just built it on a 2006 Macbook with the original spinning disk, and: 53s build time (70 cache miss compile invocations, says ccache) 1.36 MB installed package size (du of work/.destdir) so that's very small. Still, if you want to add builtin support, that seems entirely reasonable. > For instance, there has been talk for years about the possibility of > moving from CVS to git. However, it would be silly for that move to > happen before we started including git in base, or at very least had a > very much paired down, minimal git-base in pkgsrc. That's off topic for tech-pkg@ and belongs on tech-repository@! Seriously, that's not a pkgsrc issue, but a NetBSD issue. > After all, git-base has as prerequisites perl, pcre, SASL, curl > (which, as has been discussed elsewhere, includes python, libxml2 and > friends) and more. Is all of that necessary for most git use? How much > of that is there for features that are rarely if ever used? If you would like to work on making a git-microbase that is far sparser on dependencies, split out from the current git-base, that seems useful. If you mean something else other than Someone(tm) doing that, I don't follow. > While the idea of sets of package defaults was brought up and it was > decided that it's not a good idea, I think it might be worth > considering some meta-options that could be used to build very minimal > versions of commonly used tools such as curl and git-base, either for > use in small footprint VM images or in embedded systems, perhaps with > the thought of use in base later. I don't think what we do in pkgsrc for minimalizing is going to be that directly relevant for decisions in base, other than that experience with a minimal version would be useful in knowing if it's useful enough. I think what you are proposing, is something like -DSMALL, like PKG_META_OPTIONS+= SMALL where packages could then be configured (not trying to write Make) if SMALL in $PKG_META_OPTIONS SUGGESTED+= low_resource_option else SUGGESTED+= medium_resource_option endif # piggy_option is not in SUGGESTED because it drags in qt5, and it adds # a feature that is usedful to very few # SUGGESTED+= piggy_option That avoids making "turn of option X" always decisions, and lets each package be tweaked. Obviously adding more than a tiny number of these is not scalable, and distributing binary builds for even two seems difficult. But I think that people in extreme pruning mode are going to be doing builds of the small set of packages they want. But I think if we do this, it should be aimed at the extreme server crowd, and not be used to add bloat to our current defaults. Said another way, we should not expect people with a headless server to routinely define SMALL, as many such servers have normal levels of resources and are used with remote X11. That comes back to: Options are and always have a bad solution to the problem. The better solution is to have split packages or plugins, and upstreams should facilitate this. Options are the least bad solution when that's too hard. As an example, unison has a GUI option. That's not turned on because it turns the normal invocation into GUI rather than commandline, as well as dragging in GTK. This is an upstream problem, and with upstream hat on, it's in the tracker to detangle that, and I expect to end up with unison and unison-gui packages that install different binaries and don't conflict. So I would suggest that effort is better spent making options less necessary, rather than adding complexity to the options world. I suspect that dealing with fairly few packages would help a lot.
Description: PGP signature