From nobody Thu Jan 25 12:13:31 2024 X-Original-To: ports@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 4TLKVR2QlBz58PMh; Thu, 25 Jan 2024 12:13:35 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TLKVR1Ym1z4Yv5; Thu, 25 Jan 2024 12:13:35 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706184815; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zxT3Oe2DR0uYRilSAMm5l16lSZVSYULzWDd/ULIClOs=; b=php5l8YMDRYKFZhPMZKvFOMIjUlBis8uNIzQbLWJbaXQ/+dR2DXMbwo5fYx92q1O6OsLnr T046YzldQZ6xn7y9dTm8dPJ+k8zzcplPhjDsW6IdIWTueu/7L3zB9PlGVGtE9Oj6eBRVIk Fegaf2jWQ2LLsgrWXgPK9LRIPiUT8YTMoOZWKJentX7B8UU82BVOGd+SP63PpUx59cZfiD oAQhCQ31rucAUCftLOBjnolkEhliB+nG05jVfuzTWrO63Ub54TmRIwb5fA0gk7aEC6gdOT Voo2RleqkL6V2JIsZcw2EeiKYU35xdIljtpKoWRt+gOZvLWvNIu6EbiSh9UfLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706184815; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zxT3Oe2DR0uYRilSAMm5l16lSZVSYULzWDd/ULIClOs=; b=se+DaO93bvd6GfTSmv5IxufWrsUKggbQDeZMsQrf7OVXFDYR3eaNr8hBmMDwKKIEenaGVq 38mvbBMrc2evvrma3CwmLsfSa59aeR8gYm38j/CImrD//3L0//XLtlMSqgpHHG8ArnCsSX qHSiFikN1akbPIiEgVxCQWAtuGbE5/zPgok2ve8RNjRf7e4/XUxE71uKuLwlJXfoZT1dKl 8Q7xvJo7iqLebEiBQmWCZn25ShLKthf0r/db4oJmbc+irFQ6nUIOL3c6/s7oaWbLXriEFL LRfiIzoVCKC8lgK3S7fHIWem+WmszwS+pjn5cIgYWRXePqQqpxqAVpd0rnRMdA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706184815; a=rsa-sha256; cv=none; b=O5YoAzbF4yY1mbo5q6UtQ10AnxN6ddpTbwGs2qkvSes8wQsj2KnEamYxiahJwqNOB+LskS vre4Y+xjIi0PlOIcy/4CCWuIu0+O5zbmkIMAcYrOuUoRil7CSGcNW9+09PcMhucacz/1GS H0BpjexlHKHHJMwW+Gtw0CiRAG2PzOudBm4E9OCFdHJf0ADGcYFNbTXfHK49/tbaXg72x0 ddBt7sAzYbb3dNsVELFG3a5my9ovhID6Dwoi4X2gfyhDxS7VZJMwfu8MKuSTiYrNqHjzhQ dyDWcjkX5cIPbZd/AyqdKlP200HLNKoNsNWdGjJfxS5hT7XXb+M0tLdTIj5H6w== Received: by freefall.freebsd.org (Postfix, from userid 1354) id 190707D4A; Thu, 25 Jan 2024 12:13:35 +0000 (UTC) From: Jan Beich To: Luca Pizzamiglio Cc: FreeBSD Ports mailing list , freebsd-ports Subject: Re: Subpackage explanations In-Reply-To: (Luca Pizzamiglio's message of "Wed, 24 Jan 2024 10:28:48 +0100") References: Date: Thu, 25 Jan 2024 13:13:31 +0100 Message-ID: List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Luca Pizzamiglio writes: > The first use case we want to get rid of is master/slave ports when slave > ports could be built with the master port. Could doesn't necessarily mean should. For example, merging gimp-jxl-plugin back into libjxl would increase build time and risk of "missing packages" due to larger dependency chain in a port used by many directly and even more indirectly. > 2. the build is going to change the configuration of appstream, enabling > the compose OPTION, to build the dependency. Known limitation even without subpackages e.g., https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247517 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251855 https://lists.freebsd.org/pipermail/freebsd-ports/2005-August/025244.html Gentoo shows how such support may look like e.g., https://devmanual.gentoo.org/general-concepts/dependencies/#built-with-use-dependencies > * all options enabling subpkg has to be ON by default, to not introduce > broken dependencies Often already done as "batteries included" even without subpackages. > * we encourage to limit the introduction of those optional subpackages, > limiting their adoption only for cases where the related subpackage adds a > relevant set of dependencies Removing options is a POLA violation, so this may hinder subpackages adoption. What was supposed to be a mechanical change ends up requiring deeper insight into all possible use cases for a given port.