On Friday May 13 2016 03:27:54 Ryan Schmidt wrote: >> and it's probably a good idea to leave that style in >> place even after the release version of the dependency is produced. It's >> probably not because llvm 3.8.1 goes stable that there will be no 3.8.1+i >> that >> could be tested as a -devel port first. > >I don't have any interest in continuing to offer development versions of a >port that has gone stable, in the case where we offer multiple versions of >that port.
So you're in favour of providing multiple versions of a product where you stop providing updates (bug fixes, security stuff, etc) to a version once it's been released? Basically, you'd be OK with providing a series of .0 versions plus the current development version (which might be highly unstable)? Once you find that it's justified to follow a project's development with a -devel port, I don't think it's a lot of extra work (on top of the work of keeping ports up-to-date that is) when you have both in a single port directory. As long as there's development going on on that particular version you may just need to update the patchfile list of the release port (with patches from the -devel port) but I don't see a reason to remove the -devel port once you stop tracking development. Either you leave it just a bit ahead of the latest release port, or you make it a stub port that simply depends on the release port. About those dependency declarations. I wonder if the underlying implementation of a port:foo style declaration cannot be evolved to mean "port foo or a drop-in replacement". Let me explain. I've conceived my KF5 Frameworks meta-port (1 subport per framework) from scratch with the idea in mind that I might need to support -devel versions for some frameworks. So the KF5 PortGroup contains a number of convenience features. There's a procedure that takes a list of short-hand framework names and translates those into actual portnames, but the main convenience is a list of variables that contain the actual dependency statement for each framework. And those are all of the path:-style, using the main binary installed by the port. All of that is hidden from dependent ports. In this case I define those variables myself, and they're available only through the PortGroup. What if a Portfile could indicate a representative file that it installs via a dedicated keyword/command (path:-style, probably better not bin:-style)? It should be possible to obtain that information when running portindex, store it in the PortIndex, and then expand the `port:foo` expression into a path:-style dependency for ports that have used the feature. The only drawback I see is with ports that really need to depend on a specific port and no drop-in replacement, but those are probably much rarer (and it shouldn't be hard either to add syntax to depend on something like exact_port:foo). R _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
