david.sainty%dtsp.co.nz@localhost writes: > One typical solution is something like a mk/jpeg.mk file. I count at > least 189 .include "../../graphics/jpeg/buildlink3.mk" lines that > would need to be edited. Without really thinking, that sounds like the right way to go. Whether it's in graphics/jpeg/jpeg.mk or in mk probably doesn't matter too much (but I suggest surveying existing practice). I suggest looking at mk/motify.buildlink3.mk, as that's solving a similar problem, except that the issue is licensing rather than speed. But, it doesn't look like it's set up for the exactly-binary-compatible case. Also look at fam.buildlink3.mk. The perhaps-tricky part is to add a DEPENDS+= line that expresses that either is ok, but defaults to the preferred one. > Another solution is in packages like x11/libX11 which do support > automatically pulling in the non-modular alternatives. There, there is a worldview (which is accurate) that there are 2 ways to build X, and that X is special (large, important). jpeg is one of N things that has variant implementations. > A further solution might be to move graphics/jpeg into > graphics/libjpeg, and use graphics/jpeg as a wrapper package that > pulls in the preferred package. That'd save editing all the current > users of the jpeg library. The "alternatives" system looks like it > was going this route (but also seems to be a neglected project?) For source this is not too hard. For binary packages, we want a way to have both alternatives built during bulk builds, and for the other binary packages to be able to depend on either. Probably graphics/jpeg will remain primary, but if one installs libjpeg-turbo then all other packages which want a jpeg dependency should just accept it. Having a meta-package breaks this, since the default binary meta-package needs to choose.
Attachment:
pgp8X4G_K5P3n.pgp
Description: PGP signature