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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
