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.
Attachment:
signature.asc
Description: PGP signature