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