scope of FreeBSD-utilities
- Reply: Chris : "Re: scope of FreeBSD-utilities"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 16 Apr 2024 18:36:06 UTC
hello, this week i've been submitting a few patches to move things out of FreeBSD-utilities. this is the 'catch all' package that everything gets added to if it doesn't belong to another package, so as a result it contains a lot of random crap that clearly shouldn't be there, simply because no one has gotten around to moving it to the right package yet. i've been trying to address this, but i wanted to clarify what exactly should be in its own package, and what should in FreeBSD-utilities, and if perhaps we need some additional packages. i briefly discussed this with manu on IRC who said that the basic idea is that one package should constitute a definable 'subsystem' rather than a single binary, which i agree with, but let me mention a few examples i'm unsure about: - mlxcontrol, mprutil, mpsutil, mptutil - these are utilities for managing various SCSI/SAS/RAID controllers. should each of these be in their own package (following the example of e.g. cxgbe-tools) or should there be a single package for 'HBA controller utilities'? i am leaning towards the former, but this means we'll end up with a few packages containing only a single binary + manpage. - awk, grep, bc, dc, cal, etc. - i am inlined to leave these in FreeBSD-utilities on the basis that these are actually 'utilities' and having a single package that provides all of them is quite useful - or at least will be once everything else has been moved out of -utilities so the package is a bit smaller. - mt, rmt - these are niche utilities; if you have a tape drive they're essential, but the vast majority of users don't have a tape drive. so should these be in their own package? there are more examples like this but hopefully these illustrate the basic issues. i'm happy to continue submitting PRs using my best judgement for this, but to avoid wasting anyone's time (including mine!) i thought it might be useful to have a discussion about the preferred way forward here.