1 |
Hi William, |
2 |
|
3 |
William Morris <wrm@××××××××.com> writes: |
4 |
|
5 |
> Thanks for the help. I had another situation today after doing a sync and |
6 |
> trying to update (with emerge --update --deep --with-bdeps=y --newuse world). |
7 |
> The merge failed on the first of 48 (libpng). It turned out that it was quite |
8 |
> easy to fix and I did so by changing the makefile in the working directory: |
9 |
> make and then make install worked. However, that is clearly not enough and |
10 |
> emerge --resume just continued from the beginning. Modifying the tarball with |
11 |
> my fix also failed as the ebuild re-downloaded a new tarball. As you can see |
12 |
> I'm grasping... |
13 |
> |
14 |
> So what is the correct way to approach this sort of failure? Sure I should |
15 |
> report a bug (I created bug report which turned out to be a duplicate of bug |
16 |
> 465010), but after doing that, I don't want to wait for resolution if I have a |
17 |
> solution. But equally, I don't necessarily want to create a patch and modify |
18 |
> the ebuild to apply it. Is there a shortcut to be able to continue? |
19 |
|
20 |
If I were you, I'd go to test out the solution suggested by Christoph |
21 |
Junghans. |
22 |
|
23 |
adding "src_compile() { default AM_CCASFLAGS=; }" to |
24 |
libpng-1.5.14.ebuild |
25 |
|
26 |
How? |
27 |
|
28 |
$ cd $EPREFIX/usr/portage/media-libs/libpng/ |
29 |
|
30 |
edit libpng-1.5.14.ebuild and add the line. |
31 |
|
32 |
after that |
33 |
|
34 |
$ ebuild libpng-1.5.14.ebuild digest |
35 |
|
36 |
which will recalculate the manifests. |
37 |
|
38 |
Then "emerge libpng" will work in the modified way. |
39 |
|
40 |
However, if you sync your tree, this modification well be washed out. |
41 |
|
42 |
That's where an overlay steps in: a place of your own modifications that |
43 |
is "overlayed" on top of the official portage tree. |
44 |
|
45 |
Hope this explanation helps. |
46 |
|
47 |
Yours, |
48 |
Benda |