On 1/19/12 6:02 PM, Samuli Suominen wrote: > On 01/19/2012 06:56 PM, Mike Frysinger wrote: >> that doesn't help. the libjpeg turbo peeps themselves have said they >> don't >> guarantee compatibility across their own versions. > > it's forward compatible, which is all we should care about
Just a note: that'd require me to DEPEND on a recent enough version of libjpeg-turbo in the www-client/chromium ebuild, which would mean either: a) changing the virtual/jpeg dependency to >=libjpeg-turbo-... b) adding a versioned virtual/jpeg to require a recent enough libjpeg-turbo (but then what about libjpeg versions - it can easily become complicated) c) similar to a) but also adding || ( >=libjpeg-turbo-... libjpeg ) With proper SONAMEs in libjpeg-turbo that would be a non-issue (bump the SONAME on incompatible change, revdep-rebuild does the rest). > the only thing that's really broken is building against libjpeg-turbo, > and then switching to ijg's jpeg without rebuilding the package I'm fine with not supporting that, provided keywords for libjpeg are dropped (except the 62 slot iirc). > and downgrading of libjpeg-turbo I think this one should "just work", or at least not allow obvious mistakes. See my a) b) c) notes above in this e-mail for possible solutions and ideal SONAME.
signature.asc
Description: OpenPGP digital signature
