Debian/Ubuntu-style -dev ports

[René J.V. Bertin]

On Friday May 20 2016 14:54:43 Thibaut Paumard wrote:

Hi,

> normal Linux user will never need, but the normal Macports user may need
> this stuff, since the ports fall back to being built on the user machine
> in a number of not-so-rare circumstance.

Hence the idea of (semi-)automatic generation of the -dev packages and automatically adding a build-dependency on them when a port depends on the corresponding "user" port. IOW, installing that dependent port from a prebuilt package won't pull in the -dev dependency; that will happen only when you start to build the dependent.

> gigabytes of hard drive space, bandwidth, mirror space... but I guess
> most Macports users don't install the equivalent of a full OS plus
> hundreds of applications using macports, only the meaningful handful.

There are a number of cases where "split" packages can be useful to reduce the install footprint, but I didn't propose -dev ports as a way to gain some space.

> 
> In the Debian world, packages are built in headless virtualised
> environments that are thrown away after basically each package build, so
> each build only installs what is needed to build a specific package, and
> not anything that *conflicts* with this build. Bulding on consumer
> systems would mean that you would need to actively remove (or
> deactivate) possibly entire subsystems before a build can complete.

True, but I think irrelevant here. MacPorts already builds with "everything present", and that won't change if you bundle certain components of a build in a dedicated -dev port. Fortunately there are relatively very few ports that have build conflicts, even if I keep hearing from certain upstream devs that you shouldn't expect the new version of a project to build when the old version is installed in the target prefix. 
(Those must be the kind of infamous developers who don't use their own product ;) )

> Finally, the Debian/Ubuntu infrastructure provides for regression
> testing of the complex dependency relationships that emerge between all
> those tiny packages. Packages regularly become uninstallable or
> unbuildable in the testing or unstable branches, and developers are
> pinged semi-automatically to fix the issue in a timely fashion. I don't
> think Macports has the sort of manpower and resources to do all this
> automated quality assurance work...

Indeed, but again, largely irrelevant if you're only talking about putting part of a port into an optional -dev port, esp. if dependencies on those -dev ports are handled automatically. The risk becomes much larger when it becomes possible and a standard to start splitting ports up, but even then it should be a much smaller risk than on DebUbuntu because MacPorts cannot depend on specific port versions. IOW, even if you split up a port, all those "splitports" are at the same version, which doesn't really change anything. The only question is going to be how to handle a situation when some port:bar declares a conflict on port:foo-partN. Should you just conflict the whole mother port:foo, or should that be something to be decided on a case-by-case basis (because "partN" may be something that's hardly ever used by other ports while the rest of port:foo is)?

Another thing to realise is that indirect dependencies may have to be declared explicitly. Right now, port:libVLC depends on port:ffmpeg, and any port depending on libVLC only needs to declare a dependency on port:libVLC. It may however need stuff from ffmpeg's -dev port, if not only the linker libraries. I never checked if "base" handles build dependencies recursively (= installs the depends_build of all dependencies) or not.

R.