tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: graphics/jpeg Vs graphics/libjpeg-turbo writes:

> One typical solution is something like a mk/ file.  I count at
> least 189 .include "../../graphics/jpeg/" lines that
> would need to be edited.

Without really thinking, that sounds like the right way to go.
Whether it's in graphics/jpeg/ or in mk probably doesn't matter
too much (but I suggest surveying existing practice).

I suggest looking at 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

Also look at

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

Attachment: pgp8X4G_K5P3n.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index