Re: This is going to break port building without poudriere!

On Fri, Jan 26, 2024 at 11:01 AM Alexander Leidinger
<Alexander@leidinger.net> 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 subset, 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 in the main php build (if/when it is converted to subpackages). As such a build from ports will have all php extensions included in the php port installed, whereas a pkp based install can limit the amount of installed php extensions to what is required. At least this is what I understand based upon what 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 once a port is converted to a subpackages aware port (except where slave ports exclude features from binaries like git-lite... yes, git-lite is implemented 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 assume yes to both questions.  With this assumption:
>
> With master/slave ports this is possible. And replacing master/slave ports 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 packages 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.