On 04/23/2012 11:03 AM, Sebastian Luther wrote:
Am 23.04.2012 19:49, schrieb Pacho Ramos:
El lun, 23-04-2012 a las 10:17 -0400, Mike Gilbert escribió:
On Mon, Apr 23, 2012 at 8:28 AM, Duncan<1i5t5.dun...@cox.net>
wrote:
Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as
excerpted:
Title: The default JPEG implementation
[...]
All users are recommended to migrate:
# emerge -C media-libs/jpeg:0 # emerge -1
media-libs/libjpeg-turbo
That of course leaves the system without a jpeg library between
the jpeg unmerge and the completion of the libjpeg-turbo merge.
If the build process fails for some reason...
There's no way to use portage's automatic block-resolving
ability here to avoid that, I take it?
This works for me.
floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo
These are the packages that would be merged, in order:
Calculating dependencies... done! [ebuild N ]
media-libs/libjpeg-turbo-1.2.0-r1 USE="-java -static-libs" 0 kB
[uninstall ] media-libs/jpeg-8d USE="-static-libs" [blocks b
] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
media-libs/libjpeg-turbo-1.2.0-r1)
I guess it will work when jpeg is not in world file... maybe
people should be told to drop it and, then, let emerge do all the
work automatically.
There is:
# emerge --deselect media-libs/jpeg
The problem is that this would also remove things like
media-libs/jpeg:62 from the world file.
If it removes media-libs/jpeg:62, then it will say so, and they can just
add it back if that's what they really want. There's probably zero or a
negligible number of people that would have media-libs/jpeg:62 and
really want it there, so in practice we can pretend that they don't exist.
--
Thanks,
Zac
