From nobody Fri Jan 26 08:41:46 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 4TLrm830f5z57vfD for ; Fri, 26 Jan 2024 08:42:16 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (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 4TLrm81MYqz4kKw; Fri, 26 Jan 2024 08:42:16 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-f50.google.com with SMTP id a1e0cc1a2514c-7d2e1a0337bso78272241.3; Fri, 26 Jan 2024 00:42:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706258535; x=1706863335; h=content-transfer-encoding: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=uKQFnTomwaSTcSjDjYGR35XedS7Vfxxl69lagJwfim8=; b=T+fkGRU4u5ELsO/E52SEzRCduLd4iJf55MFI/VCJ/B3YbOtKMIItuFIGbLhDbJYQ+q 0b4pV/zAGvUMvgm2NK6IiaKBqxN3wHSLVE35Msz8fp2AaA2jqCwHlKjcsJtGyvzKDbrS Qso2HjTmQFBnTvQT5peRB8bq0N0LT78NbYAspZYywxQg8GpP77QE2PpUWAQA1lgzLV0o 7OS/onhS+xz8tc4cAA8TK9M0wNS4QHn/t38mLd4Jp1q2cQaHHfMALhIUvzYPp3Q9JHAK N2X/89Vt+rpjBQzSozTeXpNSqQV8zwDYgfv153VaCbQCnmaiuP0kGJ1fy2HVPoa23IBC FGsA== X-Gm-Message-State: AOJu0YyQhySyJaF3LxR7C3F2POsvNgWyFj1qvmuR4cyHrjYa+Eg+A+Fo rt7FUTFC7tg/F9aLQ+mFLG4jndmJz2oJjmKbmmcpgRXhcKoc8VtC/ApKGB1SvN8= X-Google-Smtp-Source: AGHT+IHedTfp04ShI5l1tBU/xAdL3cCUCfQ57cCrTrRsStAOhneHIbJr5I3QX5my30tmuPDs/9mu9w== X-Received: by 2002:a67:e34e:0:b0:46b:24b2:e26 with SMTP id s14-20020a67e34e000000b0046b24b20e26mr613667vsm.15.1706258534666; Fri, 26 Jan 2024 00:42:14 -0800 (PST) Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com. [209.85.221.172]) by smtp.gmail.com with ESMTPSA id e20-20020a05610211f400b0046b00db3da2sm78330vsg.28.2024.01.26.00.42.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Jan 2024 00:42:14 -0800 (PST) Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-4bdce906e11so9149e0c.1; Fri, 26 Jan 2024 00:42:14 -0800 (PST) X-Received: by 2002:a05:6122:3094:b0:4bd:7a0b:4158 with SMTP id cd20-20020a056122309400b004bd7a0b4158mr619754vkb.22.1706258534297; Fri, 26 Jan 2024 00:42:14 -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: In-Reply-To: From: Gleb Popov Date: Fri, 26 Jan 2024 11:41:46 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: This is going to break port building without poudriere! To: Alexander Leidinger Cc: Stefan Esser , freebsd-ports , portmgr , FreeBSD Core Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TLrm81MYqz4kKw 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:15169, ipnet:209.85.128.0/17, country:US] On Fri, Jan 26, 2024 at 11:01=E2=80=AFAM Alexander Leidinger wrote: > > Am 2024-01-25 20:57, schrieb Luca Pizzamiglio: > > > I think Stefans expectations about such a feature are different from the = understand of the implementor of the feature in our tree. Somewhat a clash = of an idealistic view and reality. > > To me (and I assume to Stefan too) it looks like slave ports will go away= and subpackages will be used instead. A slave port may only compile a subs= et, and a subpackages aware port will compile everything (simplified view, = not true where slave ports exclude a feature instead of excluding a file). = From this point of view, a port can not depend on a subpackage in the sense= of a port can not depend only on a subset of the php extensions included i= n the main php build (if/when it is converted to subpackages). As such a bu= ild from ports will have all php extensions included in the php port instal= led, whereas a pkp based install can limit the amount of installed php exte= nsions to what is required. At least this is what I understand based upon w= hat I have read about subpackages. As the documentation is not ready and I = haven't looked at the code, this understanding may off course be wrong. > > Is my understanding correct that subpackages aware ports are supposed to = replace master/slave ports? In the sense of slave ports will be deleted onc= e a port is converted to a subpackages aware port (except where slave ports= exclude features from binaries like git-lite... yes, git-lite is implement= ed as a flavour and as such we cover this in a different way and such slave= ports if they still exist can maybe be converted to use flavours)? I assum= e yes to both questions. With this assumption: > > With master/slave ports this is possible. And replacing master/slave port= s with a subpackages aware port will remove this possibility. Subpackages are not a master/slave ports replacement, nor vice versa. Both you and Stephan seem to mix a lot of concepts which causes all that confusion. The idea behind master/slave ports **templating**. The master Makefile serves as a template and the slave Makefile overrides some variables and/or targets. This is a very general technique which allows for implementing many things. Including subpackages, by the way! Look at how devel/appstream and devel/appstream-qt are implemented. The idea behind subpackages is producing multiple packages from a single build (a single work/ directory). This idea is simple and concise in its shell. It can be applied right away without literally degrading anything else, but for now it requires much caution (again, see the revert commit for my attempt to subpackagize devel/appstream). Finally, ports are mostly declarative build recipes, a pile of variables and some command invocations that **describe** something. Subpackages allows us to refine the description of a given software product by saying "From the resulting build artifact we can pick out this and that into their own package". Nothing is broken in Ports. The breakage you're talking about is the breakage in **interpretation**. Dependencies describe relations between the **port** we're building and **packages** it depends on. It might be confusing at first, one may argue "but I do see ports origin in the *_DEPENDS lines!". Yes, but origins are there for convenience only. It is the part that precedes ":" which matters - it declares what the port is requiring. Where to get it is actually an orthogonal question and we already have two options for that - a package repository and compiling a port (and this is where the origin after ":" comes into play). Note that in the resulting package all dependencies do not contain origins - exactly because they are an additional info provided for convenience. > What is broken is that you _have_ to install such dependencies via packag= es in this case if you want to have the minimal install. There you're talking about a one specific interpretation, a naive one. It build down to just "make"ing the Makefile. This approach still works, but there is a fundamental problem with building on host (aka "not in poudriere"). Building on host requires you to install even BUILD_DEPENDS (and transitively!). Are you OK with installing BUILD_DEPENDS for a given port? Then subpackages doesn't even install anything, they only require building more and only under certain circumstances (when the subpackage is not hidden behind an option). With all this said, what's exactly broken for your case? You're building/installing too much? But you were installing much more by BUILD_DEPENDS, so it is hardly an argument. Heck, when using build-on-host to install a simple Haskell program, you need to install a 1Gb Haskell compiler package as its BUILD_DEPEND! P.S. I made a little writeup on Ports features, which tries to explain what subpackages really are. You might find it useful: http://arrowd.name/ports_writeup P.P.S. It took a while to properly trim quotes from your message, because your mail software did not mark Stefan's message as quotes.