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

[René J.V. Bertin]

On Wednesday April 26 2017 17:32:58 Rainer Müller wrote:

> 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.

Hmm? You mean the Portfiles? That's not really different from Debian and presumably RPM-based systems, which also have a local database that tells them which packages are available (and that usually allow to install from source too).

One fundamental difference with Debuntu and RPM packaging (AFAIK) is that those always involve the binary package (.deb or .rpm file). Even if you build a package from source that is part of a source package generating 10 other packages you'll end up with all those .deb or .rpm files somewhere, but install only that single package plus its dependencies.

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

Well, that's because even for "dev" content it's a bit too port-specific what qualifies so the ultimate archive creation step has to be made explicitly in the Portfile. For instance in my Linux version of port:tiff :

{{{
post-destroot {
    if {${subport} eq "${name}"} {
        register_devport_standard_content
        devport_content-append ${prefix}/share/doc/tiff/html
        devport_content-append ${prefix}/share/man/man3
        create_devport_content_archive
    }
}
}}}

The register_devport_standard_content step could indeed be done in the PortGroup, though that would mean that the port cannot modify things in that standard content in its post-destroot .

> 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.
> 

Why? Installing from the custom tarball uses the same kind of install mechanism that ports use that install content not needing any building: the file tree is created under $destroot in the destroot step, which is then installed as usual. Believe me I've tested the subport de/activation as that was the whole point of the endeavour. Being able to avoid build conflicts by (temporarily) removing just the files that could affect a build, not the runtime files.
That's also why I can remove the custom tarball once the -dev port is installed: it isn't needed anymore (and can be regenerated by de/re-activating the main port).

> 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 only difference here is that I'm not (yet) creating anything that looks like official packages, but put install certain files in latent fashion.

Which reminds me that another way to achieve this particular goal would be to move (hide) those files without archiving them, and then set up symlinks as appropriate in the -dev port's destroot phase.

> 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. ...
> 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.

Maybe we're thinking along the same lines, but what I'd do is modify the existing phase that comes after the post-destroot. Currently that involves installing ${subport} from everything that is found under $destroot . It should be relatively straightforward to extend this to support multiple destroot directories. To stick with the -dev port example, you'd
- associate port:foo-dev (${subport}==${name}-dev) with "${destroot}-dev"
- during the usual install, MacPorts now installs the $destroot dir as ${name} (port:foo) and ${destroot}-dev as ${name}-dev (port:foo-dev).
- Of those two, only the one(s) of which an install or upgrade was requested (or that were active before) are activated; the other(s) are not.

There may be side-effects here that I am overlooking and I don't know if it is any simpler implementation-wise, but it does seem to fit in well with the traditional MacPorts approach of just installing everything.

It's basically adding install labels that allow you to de/activate a port in one or more sections. That part will probably indeed have to be done in Base.

> 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

That's already what happens, no? 

> 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.

Or as I said, a new property that determines from what directory (sub)ports are assembled and whether they build as standalone ports.

Evidently there are other applications for split ports besides not installing development content unless it's needed. There could be an advantage for the llvm/clang ports to use a build once, bundle twice approach too and there my current approach might be less appropriate.


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

Is that very different from Debian's system where there is 1 file that defines the (sub)packages provided by a source package (metadata), and then 1 .install file per package that lists the files which are to be provided by that package?
Clean and simple, though I often miss the programmatic approach used in Portfiles.

> 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.

Yeah, or you find a workable solution that provides new features using the building blocks that do exist. If that turns out to be useful and popular you can always integrate the functionality into the kernel and improve on it. You'll have noticed how the whole aspect of how the -dev subport is created is hidden, and can thus be changed completely.

R