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

[Rainer Müller]

On 2017-04-26 19:11, René J.V. Bertin wrote:
> 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).

No, this is not true at all. You can install a .deb or .rpm without
having a corresponding local index. In case of Debian, installing
packages is even fully separated in two tools (dpkg and apt).

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

That is it exactly. This is the way it should work.

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

No, not as far as I understand it. As you sketched it, you would first
have to download foo, which then contains the tarball for foo-dev.

That means, if I am only installing foo, it will waste bandwidth and
disk space for foo-dev, even when I am never going to install foo-dev.
Isn't the idea of splitting to avoid that?

If your only goal is to activate files separately, but still ship all in
the same pre-compiled archive, why not modify the activate phase to
support that? That would sound a lot simpler.

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

That is actually the better use case than creating separate -dev
subports in the way of Debian/Ubuntu.

As soon as some dependent needs to be built from source, we would still
have to specify every single -dev subport in its dependencies...

Rainer