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

[René J.V. Bertin]

On Thursday April 27 2017 11:37:41 Rainer Müller wrote:

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

You're right, I forgot about standalone .debs. Regardless, I *think* that the apt system calls onto dpkg to handle the ultimate installation.

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

I meant the way MP works currently, not my -dev implementation. The latter indeed provides the install "media" for foo-dev in the tarball for foo. Which is nothing other than an easy implementation of keeping part of the port deactivated by default.

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

That's one of the ideas, yes. But also a consideration that MacPorts has never really made. My main reason here was avoiding build conflicts without having to deactivate an entire port which can have far-fetching implications. On Linux for example I had to do an annoying dance deactivating port:gettext (and git, for some reason) in order to build Qt, which meant I couldn't use many of my installed ports. Now, I can just de- and re-activate gettext-dev when needed.

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

That would be another solution, but that would also mean modifying the depspec mechanism one way or another.

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

Depends on the hat you're wearing. From a developers' (but also distro maintainer's) point of view the possibilities provided by installing runtime and development payload separately are probably more useful than gain of disk space. And the advantages of creating multiple packages from a single build disappear for end-users when you can simply install binary builds.

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

Yes, dependent ports will need to adapt their depspecs. I don't see this as something that ought to be used indiscriminately.
A good example where this feature could (have been) useful is port:ffmpeg. There's still at least 1 port that doesn't work with ffmpeg 3 (VLC), which now provides a private ffmpeg 2.8 subport . With a -dev split it would have been straightforward to implement a more or less temporary port:ffmpeg2 ; port:ffmpeg2-dev would have conflicted with port:ffmpeg-dev, port:VLC would have had `depends_build-append port:ffmpeg2-dev ; depends_lib-append port:ffmpeg2`. Much easier and quicker to implement than the hoops I had to jump through to get the current implementation to work.

R.