From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F3414C6804 for ; Thu, 3 Sep 2026 14:58:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=140.211.166.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788447503; cv=none; b=GOsc+cSn2lPOyNLcKbf5TdMC9NbabY9OvVR1j3/CiFI3lkdQ/+eHgK4UUumyFYZQ7BhLrQrFYcsy4zUlu0fjlD9jjzJerK5QjkM0E368UZzc1UuMAt2xybqWViYL2Og/EPLyfiBoTVhvh27+DARzgpo5CoZEwZb/oH0nza8IZDE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788447503; c=relaxed/simple; bh=VM2WKL5h0rPp2cbZJVFQ/Oa6RuizESE3mfG26QOm4ro=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=GmRpnrTkmgybv7brG4CGAtRqNFkId0AFt65ZwKjTBqtHq8aylWqA0CVxLzU5Dw9MYG/0AaGTgSUPYvduCtFDon+243++aLc0cw+X3RILfBdpD+kMWitg2+dpvoTraG/mkE5Z7PlYw1EPcH5E4v+fwuE3mc1+A7klKYcS3HeLQmg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gentoo.org; spf=pass smtp.mailfrom=gentoo.org; arc=none smtp.client-ip=140.211.166.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gentoo.org Received: from mop.sam.mop (c.1.a.0.0.0.0.0.0.0.0.0.0.0.0.0.a.5.c.d.c.d.9.1.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:19dc:dc5a::a1c]) (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) (No client certificate requested) (Authenticated sender: sam) by smtp.gentoo.org (Postfix) with ESMTPSA id 9CC78341F15; Thu, 03 Sep 2026 14:58:19 +0000 (UTC) From: Sam James To: "Christopher J. PeBenito" Cc: selinux-refpolicy@vger.kernel.org, Rahul Sandhu , Eli Schwartz Subject: Re: RFC: Build system change In-Reply-To: <2f2378c3-b593-40ff-b2a0-8e7bdd43497d@ieee.org> Organization: Gentoo References: <1ed386f1-4110-44f1-8547-cdaa1ca03111@ieee.org> <87jyp2ittj.fsf@gentoo.org> <2f2378c3-b593-40ff-b2a0-8e7bdd43497d@ieee.org> User-Agent: mu4e 1.14.3; emacs 32.0.50 Date: Thu, 03 Sep 2026 15:58:14 +0100 Message-ID: <87ld9igz5l.fsf@gentoo.org> Precedence: bulk X-Mailing-List: selinux-refpolicy@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Christopher J. PeBenito" writes: > On 9/3/26 5:10 AM, Sam James wrote: >> "Christopher J. PeBenito" writes: >> >>> Back when refpolicy started, every system carried the policy sources >>> and built its own policy locally. Given that world, *make* was the >>> obvious choice =E2=80=94 ubiquitous, lightweight, and well understood. = The >>> downside is a set of Makefiles that=E2=80=99s hard to read and even har= der to >>> maintain. >>> >>> Fast=E2=80=91forward to today, and no one is building full policies on= =E2=80=91device >>> anymore. Outside of a few local modules, the main policy is built by >>> the distro. With that in mind, I=E2=80=99d like to move the main policy= build >>> to a modern system (the headers=E2=80=91based builds would stay on make= ). >>> >>> I=E2=80=99ve been experimenting with *meson/ninja*, and so far the resu= lts >>> look good. I=E2=80=99d appreciate feedback on two points: >>> >>> 1. >>> >>> *Concerns about making this change* >> >> We'd lose the ability to quickly run make for a single policy being >> developed before it moves into proper packaging, I think, but we could >> keep simple Makefiles around for that case. > > When you say single policy, do you mean a full build of > standard/MLS/MCS or an individual policy module like "make > modulename.pp"? > Ah, sorry, I meant "make modulename.pp" when working on something new. > >>> 2. >>> >>> *Which build system we should adopt (I'm definitely not attached to >>> meson)* >> Meson is usually the nicest to deal with as a distribution maintainer. >> >> I'm also a Meson contributor. I think Rahul was interested in adding >> SELinux policy support natively into Meson too. >> > Can you clarify what that means? It seems like a very specialized feature. Not needing custom_targets to build policy files, so benefitting from proper typing and native Meson objects for it. Meson already has them for various languages and it welcomes more of them. I think he had some specific benefits in mind but I'd have to ask him what they were again. sam --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEBBAEWCgCpFiEEJaa7iN2bdkxrVUHCc4QJ9SDfkZAFAmqZiwYbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyNUE2QkI4OEREOUI3NjRDNkI1NTQx QzI3Mzg0MDlGNTIwREY5MTkwDxxzYW1AZ2VudG9vLm9yZwAKCRBzhAn1IN+RkHDU AP4xAGoyyRe0FncJNgJpsfisZYBiwU2Tc2+C4eBK8Q2MQwD+O8i8Waky73keE+1j RhiNyEA50r0GYm9z5WA+HTwmlgc= =TZvL -----END PGP SIGNATURE----- --=-=-=--