Alexander Vasarab <alexander+nettp%vasaconsulting.com@localhost> writes: > On 11/10/15 10:55 -0400, Greg Troxel wrote: > >>For curses, it probably makes sense to avoid it, to keep cunit leaner. > > It's unclear whether you mean to avoid enabling by default, or to avoid > adding an option for it. I meant to avoid enabling by default. So an option is fine, I think. >>For the three you are proposing to default to on, how many people do you >>expect would ever want to disable them? It may be that just having them >>on without an option would be fine (but I have not looked). > > Good point. I think that very few would people ever disable them. If there is no rational reason to disable them, it might be better to just enable them and not have an option. >>Would you see the 3 cunit variants building without curses and being >>useful, in the state you propose? > > They would be useful, sure, but I think that the above point trumps. A > common reason for disabling, e.g., all but one interface would be that > your environment is severely constrained and you simply don't have the > budget for a larger object. Such an environment would not likely be > using pkgsrc directly anyhow. It could, but so far pkgsrc has not really been set up for super minimal. > Perhaps a more reasonable change would be that devel/cunit gains one > option: > > curses (default = "off") > > In this way, binary packages would be unaffected, show-options would not > be inundated with superfluity (and thus mk/defaults/options.description > doesn't gain a bunch of non-general items), and users would gain the > ability to optionally use a useful feature. That sounds ok to me (not really understanding the details of cunit usage).
Attachment:
signature.asc
Description: PGP signature