"dev" ports (=/= "devel" ports!)

[Rainer Müller]

On 2017-04-26 14:15, René J.V. Bertin wrote:
>> I really really don't think a PortGroup is the right way to do
>> this. This should be done in base, with proper support of creating
>> multiple packages from a single build and then optionally
>> installing some of them, more like FreeBSD's ports does things.
> 
> As often I use a PortGroup only because it's a much more convenient
> way to develop and test new functionality, esp. the part that cannot
> be automated reliably anyway (indicating which files and directories
> have to go into the -dev port, or any number of "sub" ports).
> 
> We don't know how many ports would be using the feature, so why spend
> time and effort making possibly complex changes to Base until we know
> that?

In my opinion splits in the way they are done on Debian/Ubuntu or with
RPM distros makes a lot of sense for binary-only distributions. Ports
system work in a different way and usually do not implement such a
feature. At the moment, MacPorts is kind of a mix. You can install from
source, but skip the compilation with pre-compiled archives. These are
not real packages, as they cannot be installed standalone without a
source ports tree.

I do not understand how your provided Port Group is supposed to work,
because 'create_devport_content_archive' is not called anywhere.

But if I get it right, you want the main port to ship tarballs that
contain the files that will only be activated when installing the
subport. This is a bad hack and is way too fragile, as de-/activate on
the subport will inherently be broken, unless the main port is active.

The way this is done with other systems is to destroot once, then put
files as specified into separate packages. Each resulting package can
then be installed just as any other package.

The way this could work in MacPorts would be to have a new phase for
packaging after destroot and create multiple binary archives from one
Portfile. On installing, port would first check for a binary archive and
if it exists, it is downloaded and installed as usual. Only if it does
not exist, we need to do build/destroot/package the parent port. Since
everything will need to be built anyway, we can install and register all
packages in the local system, but only activate the requested subport.

Instead of developing this in a port group, it seems much easier to me
to do that in base, especially as this would become a new type of port
besides the existing subports.

For the syntax, I would recommend to look at the way RPM allows to
define splits/sub-packages.

> There's also the point that ports using this particular new feature
> would impose users to upgrade if it's implemented in Base. I don't
> know if that'd be a precedent, but wouldn't like it if it is. I'd
> prefer to see Base as a kind of microkernel with a modular
> architecture (but that's just me).

New features have always been part of base. What you want to do is
something base was not designed for, so the framework needs to be extended.

Rainer