What are the benefits of NO_ARCH?

[Baptiste Daroussin]

On Tue, Nov 03, 2020 at 01:41:54PM +0100, Mateusz Piotrowski wrote:
> On 11/3/20 11:24 AM, Mateusz Piotrowski wrote:
> > On 11/2/20 3:50 PM, Baptiste Daroussin wrote:
> > > On Mon, Nov 02, 2020 at 03:48:34PM +0100, Stefan Esser wrote:
> > > > Am 02.11.20 um 15:33 schrieb Mateusz Piotrowski:
> > > > > I wonder if setting NO_ARCH=yes brings any significant benefits to how
> > > > > our ports collection works. I'd be grateful if you could shed some light
> > > > > on the importance of setting NO_ARCH whenever possible.
> > > > NO_ARCH means that there is no need to build packages for each of the
> > > > supported architectures, e.g. for pure interpreted scripts or data files
> > > > that do not depend on byte-order and word-size (e.g. many font file
> > > > formats).
> > > > 
> > > > The result is reduced resources spent on building the packages, network
> > > > traffic, disk space on mirrors and on distribution media.
> > > Yes that is the goal, in practice it is not yet the case, so it is purely
> > > informational, but that what we are aiming at yes.
> > 
> > Thanks!
> > 
> I've added a note to the porter's handbook based on the information you provided:
> 
> https://svnweb.freebsd.org/doc?view=revision&revision=54671
> 
I think you have been a little too fast.

The point of no arch is not only that. pkg checks if a package is a valid ABI
for the system it will install to. This is done via globing on the ABI variable.

When a package is set to NO_ARCH: you end up this is line: "FreeBSD:13:*"
meaning the package can actually be installed on any freebsd 13 system. so it is
already useful as of today. what Stefan describe is other things we might
benefit one day thanks to have the NO_ARCH packages already in the futur.

best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20201103/e00e1648/attachment.sig>