From nobody Tue Apr 16 19:00:40 2024 X-Original-To: pkgbase@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VJtfR5p9Yz5HN27 for ; Tue, 16 Apr 2024 19:00:47 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJtfR46Dmz4m47 for ; Tue, 16 Apr 2024 19:00:47 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 43GJ0emv096419; Tue, 16 Apr 2024 12:00:46 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1713294046; x=1713294646; r=y; bh=TuV0WzaJKl/ZgPnfAApaMoEC/E8+bgEmUvHTYzCve08=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=lU72+fUKFWYI5BAODcZGV1UBvJBnHE3F3BfYfOQYKkFedWpguJ89XGhkNPdENewlF eT+DHxaPlD5SobFRvBaByk6BlEJCVaHhirzYeOLRfhuva22MT7MKxAZIvclN/fZjtk +FDcbzDGvqgqmiGcKQIFxbzRc1e2rusgBs0XC4JcZEFXb0r5Wkn+yWnl0dIHMsaOL7 ZdXrYGMmG9kwfc3+nF+h8MQDUVKOJpwfEm2HkAnrH+fscveIQ+pXpa/8j58m/CDrIa 2dXIDOoxHMp5SwQz/bexjAoKM8nFLexAG9BIwQh+T67CKQMfxYw5I1QdoV35YIHijV d6IeF76KX/Trw== List-Id: Packaging the FreeBSD base system List-Archive: https://lists.freebsd.org/archives/freebsd-pkgbase List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkgbase@FreeBSD.org MIME-Version: 1.0 Date: Tue, 16 Apr 2024 12:00:40 -0700 From: Chris To: Lexi Winter Cc: pkgbase@freebsd.org Subject: Re: scope of FreeBSD-utilities In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4VJtfR46Dmz4m47 On 2024-04-16 11:36, Lexi Winter wrote: > 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. agreed, former (each to their own package) > > - 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. Leave in. > > - 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? > own package (inclusive) > 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. In closing; Not having looked at the Makefile, Is this option-based? IOW can the user simply tick off any/all of the individual items included in the port? Thanks. --Chris