From nobody Fri Jan 26 11:42:49 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 4TLwmy4NYcz58Ccr for ; Fri, 26 Jan 2024 11:43:14 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-256)) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TLwmy2pvxz44b1; Fri, 26 Jan 2024 11:43:14 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1706269389; 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=EaGVdEMldQ2eqs2mfktXF1tNZLBDFJ1ZRwdgdaZ2PAg=; b=H2ml6p7SurTsdLoujt2CayLF+CoFG9Ftuyx2qlcnX7rRSGiVK007hb4NU7Lxkx/NEivQQh vNH9tMg5S3pguRH096atGywpKyWBYOQEwlF6GpsWvxR9lce7BAyTDjdtdPwPLqIHIKbgCb jgGXc6V4942d2NXtI1W4I8/ZCG/lm8rQ2mqPm/o2c/2NRKij6MNXTtOBMJAyDVTccVagCc Zm64iH0oM9NsFIFl8QTzDzV/VI+HWOH49kZD0smv/mvtPuclbHdJ/lOuaDuFgEtk1SClFA WUllP+BpyyJTrNWMN4s6OPVGh89Gn2WSQvKtnsqbtoDkj4fUJRXIMafgGknJEA== Date: Fri, 26 Jan 2024 12:42:49 +0100 From: Alexander Leidinger To: Luca Pizzamiglio Cc: Gleb Popov , Stefan Esser , freebsd-ports , portmgr , FreeBSD Core Team Subject: Re: This is going to break port building without poudriere! In-Reply-To: References: <4b1f2470bf476f0f9e8f8b689c585c43@Leidinger.net> Message-ID: <23b92b0af455f815a647497646b0e47f@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_37d0472fe1ad63f6c9844c254e3276d6"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4TLwmy2pvxz44b1 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:34240, ipnet:2a00:1828::/32, country:DE] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_37d0472fe1ad63f6c9844c254e3276d6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-01-26 12:12, schrieb Luca Pizzamiglio: > 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. Thanks for confirming. IMO you overlook the fact that there may be people eager to convert to subpackages. If we would adopt the policy to provide -lib ports, I would jump on converting audio/lame to a libraries and frontend subpackages aware port. Some stuff only needs the lib and not the frontend. It may be a small change for the ports collection, not relevant for the ports build cluster, not relevant for all users, but I would do it quickly. I'm also looking forward for debug-symbopls packages. I think this is a very nice and good idea and would ease some cases where I was spending time to rebuild packages with debug symbols to find the cause of issues. So what you have is a good first step, but in the current state requires strong governance in my point of view. More below. > 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. php82 was simply a specifc example, there are surely other ports which fall into the same case. I don't mind to convert existing stuff to subpackages, if there is no discrepancy between "make install" and "pkg install". I would even think it would be a good idea to convert from a global point of view, it could cut down the build time on my poudriere instance. > 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 dependency list for pkg users would stay the same, wouldn't it? The amount of dependencies for a given port doesn't change, only the origin. If phpXX-zip is available as a subpackage, the origin doesn't matter. But if a port install also installs phpXX-xml together with phpXX-zip if it has the same origin, but php-XX-xml is not in the dependency list, that would be a severe regression as it may have security implications (again, just an example what can happen, but one example which we need to take into account while thinking about subpackages). > * 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 I would rather describe this part as "being able to depend on a specific subpackage and not the complete origin in make based port installs" to have a converted lang/phpXX not install more dependencies for mail/roundcube on make install. > * 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. The concept of subpackages is IMO suitable for php. I fear that there is a faster adoption of this feature than you want to advocate for. That's the reason why I think that the current implementation should keep the apporval-lock by portmgr, and a veto from portmgr for ports where the change to subpackages would results in a change of the origin of the dependencies (with lang/phpXX as a prominent and best example of what I mean with that). And this veto should be kept until the subpackages implementation allows to have "make install" and "pkg install" result in only the minimal dependencies being installed (= until the missing feature you talked about above is implemented in a way that make install in mail/roundube only installs those php extensions it requires). Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_37d0472fe1ad63f6c9844c254e3276d6 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmWzmskACgkQEg2wmwP4 2IZmrg//frgri39aH88RCfNEV0W+Cf793DeE2sMNnb9nird2kk4y6IRlVt5pG0AP 3b92f1QQTcAKec120J9ENbOcLOg8dVgvOobT/msSJxjNj6s/qUqBCaX3HTxSy5S4 LyfRZA8qtCR9laJlX/iXkbivmRi3Un0udrlWiQGeTBLVcLNPJXfQY1SRPAoS+5DQ R1YPFzxYLFmVux7lbgIoWfseffLJkWq9i9n9Miz/Rntsvw7NVKIoj/Zw3dzLAx4W w3Re0VoyifoSTD05JVyRpzFk/mzFLMxU+K8N+Lem4Uw55y8socCQThJAJOgtzAuw lV7IyoZkzafGtC15IJJLJC1NN21fdpgm5LONG1B14PRcLbwOvhX1RtUaYU4THcRs WtQ3I0bJ1yr/nmS9Vw9zp53utIb5hSV7xvfNRh+Im4mLn4YCevtkv1ogZdgEcWc5 85rIK7g5O8fo2dBPHM3ls+GhmK7QOai2r4p2YTzoz08n5c4Z/XEqg0ThFc1Z0vNA GOg9kQpZe9kW6gEaYNo4VV5OYDya82Cl7HXm4Qf6jvXFsqnnWpZaoji34Dkb3Bix KDGqx3kMY+uZ6gmkDfQtfrZAXSKMhDWGYr1i7qrsLfrg+0RJPCjipoP/90SQO+hD fewZttZyzez7wC8GGd56ITx6FmeeSCuPHhCLsVtrjJ22HPdNHt8= =AwVd -----END PGP SIGNATURE----- --=_37d0472fe1ad63f6c9844c254e3276d6--