From nobody Fri Jan 26 11:12:01 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 4TLw5L2DpMz588pq for ; Fri, 26 Jan 2024 11:12:22 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TLw5L0ckGz424b; Fri, 26 Jan 2024 11:12:22 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f54.google.com with SMTP id ca18e2360f4ac-7bed8fee278so9707339f.2; Fri, 26 Jan 2024 03:12:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706267538; x=1706872338; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hIGglJqvTL6ZOQdK+Cu1CRw7uXnCiTO5fkwh3CgygiQ=; b=kkAOS0OHdRF0eWCyUvEPhQA1bFXk8SW8Q8aSkSBpOclg7N8V5lRgxk5kqA7AyJyhj/ XI6ebjUc0i0mK9BF5e8hcPOQo35xRdvN3MqW5uj7znhsceZh+RBNCT9IA1QKdPx+Ai49 04vrKH0V/6tGyMx3UVLEg8qx6NgAPBsZ4XjxKAHydRaK9OgccOtNhVzJhYQk/keDs+gW dQgeqyeRKN2C7ONue0KOxpCfzxglDbLjYoeo5ebupDZPcFlKPl2a5awWv3z2ADYajxgH Gy4nbp6DXuNOjkbANhId2q1y4K+DzsB0X7HV0FqTbzmRxZ2dbOmjnk6tCp9pUsD8a704 pK8Q== X-Gm-Message-State: AOJu0YxrHHPcy/U+9c+5fUbkfe7P0BgqMtWIQ3DWT+FBCUprCfJ40DzR RyGv5vdev8yi5IXXrhGfWAY04aqZfnWPzrrz9WZJgh+jPaHU4S69K/bJZc22yq4= X-Google-Smtp-Source: AGHT+IFGVE4ZKW8u0jB+AWTkQRvmG3t2Q5U6Vv9ATn4sxG/+5OAEVcGGWu+kv8yjDmx9f6lVA1zP4g== X-Received: by 2002:a5e:d802:0:b0:7bc:1bf9:fd83 with SMTP id l2-20020a5ed802000000b007bc1bf9fd83mr1848867iok.3.1706267537733; Fri, 26 Jan 2024 03:12:17 -0800 (PST) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id fh2-20020a056638628200b0046f394096ddsm239030jab.105.2024.01.26.03.12.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Jan 2024 03:12:17 -0800 (PST) Received: by mail-il1-f178.google.com with SMTP id e9e14a558f8ab-3608aa647bfso191235ab.3; Fri, 26 Jan 2024 03:12:17 -0800 (PST) X-Received: by 2002:a92:c0c1:0:b0:361:a9fc:f260 with SMTP id t1-20020a92c0c1000000b00361a9fcf260mr1348823ilf.6.1706267537352; Fri, 26 Jan 2024 03:12:17 -0800 (PST) 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 References: <4b1f2470bf476f0f9e8f8b689c585c43@Leidinger.net> In-Reply-To: <4b1f2470bf476f0f9e8f8b689c585c43@Leidinger.net> From: Luca Pizzamiglio Date: Fri, 26 Jan 2024 12:12:01 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: This is going to break port building without poudriere! To: Alexander Leidinger Cc: Gleb Popov , Stefan Esser , freebsd-ports , portmgr , FreeBSD Core Team Content-Type: multipart/alternative; boundary="00000000000074ae95060fd75e9c" X-Rspamd-Queue-Id: 4TLw5L0ckGz424b 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)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] --00000000000074ae95060fd75e9c Content-Type: text/plain; charset="UTF-8" Hi Alexander. You understand correctly what I wrote: * Several master/slave ports can be converted to use subpackages. * Php is a potential candidate for subpackage adoption However, I wasn't explicit on the fact that I won't impose subpackages adoption on anyone. Specifically, I don't want to convert php into subpackages right away, there are smaller/easier examples to tackle first. And in general, the maintainer is the one making the decision, and they can disagree with me. An experimental adoption will be considered for lang/php83, existing versions won't be converted. As you pointed out, there are two challenges specifically for php: * moving all extensions (slave ports) to subpackages in lang/php* can significantly increase build times (for ports users) and its dependency list (for pkg users) * the meta php-extensions port is a convenient way create a custom group of extensions Php port could be converted into subpackages if and only if we can provide a similar experience as before. To do that: * we would need to add options to enable/disable extensions, in order to manage build times and dependencies * we need to provide the similar meta php-extensions package, as it's largely used If the maintainer finds out that subpackages are not suitable for php, they won't be adopted. Best regards, pizzamig --00000000000074ae95060fd75e9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexander.

You understand= correctly what I wrote:
* Several master/slave ports can be conv= erted to use subpackages.
* Php is a potential candidate for sub= package adoption
However, I wasn't explicit on the fact that = I won't impose subpackages adoption on anyone.
Specifically, = I don't want to convert php into subpackages right away, there are smal= ler/easier examples to tackle first.
And in general, the mai= ntainer is the one making the decision, and they can disagree with me.
<= /div>
An experimental adoption will be considered for lang/php83, exist= ing versions won't be converted.

As = you pointed out, there are two challenges specifically for php:
*= moving all extensions (slave ports) to subpackages in lang/php* can signif= icantly increase build times (for ports users) and its dependency list (for= pkg users)
* the meta php-extensions port is a convenient wa= y create a custom group of extensions
Php port could be conve= rted into subpackages if and only if we can provide a similar experience as= before.
To do that:
* we would need to add opt= ions to enable/disable extensions, in order to manage build times and depen= dencies
* we need to provide the similar meta php-extensions = package, as it's largely used

If the maint= ainer finds out that subpackages are not suitable for php, they won't b= e adopted.

Best regards,
pizzamig

--00000000000074ae95060fd75e9c--