| 1 |
coorect, you could concievable run something like |
| 2 |
ebuild ebuildname qmerge if all the steps have been completed |
| 3 |
|
| 4 |
-Kevin |
| 5 |
|
| 6 |
|
| 7 |
On Thu, Dec 6, 2012 at 1:44 AM, Alan McKinnon <alan.mckinnon@×××××.com>wrote: |
| 8 |
|
| 9 |
> On Thu, 6 Dec 2012 08:45:10 +0100 |
| 10 |
> Willie WY Wong <wongwwy@××××××××××.org> wrote: |
| 11 |
> |
| 12 |
> > Hi list, |
| 13 |
> > |
| 14 |
> > Suppose that I tried to emerge a package, and the compilation phase |
| 15 |
> > went through without problems, but it got stopped in the installation |
| 16 |
> > phase. Is there a way to (after I fixed the problem) to tell portage |
| 17 |
> > to install the (now all already compiled binaries sitting in |
| 18 |
> > /var/tmp/portage) directly without having to redo the compiling |
| 19 |
> > phase? |
| 20 |
> |
| 21 |
> not with emerge, but you can use the lower-level command ebuild for |
| 22 |
> that. |
| 23 |
> |
| 24 |
> portage & ebuild are analogous to yum & rpm or to apt* and dpkg |
| 25 |
> |
| 26 |
> man ebuild for more info |
| 27 |
> |
| 28 |
> > |
| 29 |
> > Case in point: |
| 30 |
> > |
| 31 |
> > I just tried to update dev-lib/boost to 1.52. The compilation went |
| 32 |
> > without a hitch, but the installation died because of file collision |
| 33 |
> > against (I think) boost-1.49.0-r1000. Now that the colliding files are |
| 34 |
> > no longer there, is there a way to tell portage to go ahead an install |
| 35 |
> > boost-1.52 from the compiled sources in /var/tmp/portage ? |
| 36 |
> > |
| 37 |
> > Thanks, |
| 38 |
> > |
| 39 |
> > W |
| 40 |
> |
| 41 |
> |
| 42 |
> |
| 43 |
> -- |
| 44 |
> Alan McKinnon |
| 45 |
> alan.mckinnon@×××××.com |
| 46 |
> |
| 47 |
> |
| 48 |
> |
Archives