| 1 |
On Mon, 4 Dec 2017 03:58:40 +0100, tuxic@××××××.de wrote: |
| 2 |
|
| 3 |
> what could fail, when doing the change to PIE-enabled applications |
| 4 |
> on base of the regular updates? |
| 5 |
> Compilation may fail, if libs are included and not flagged as to be |
| 6 |
> recompiled, which are of the "old standard"... |
| 7 |
> What else can fail? What may be the worst scenario? |
| 8 |
|
| 9 |
Anything. You are rememrging packages that may have changed, or their |
| 10 |
dependencies, so you are bound to find the odd problem. |
| 11 |
|
| 12 |
> Is there a way to do a "emerge -e @world" but only for the system |
| 13 |
> applications? |
| 14 |
|
| 15 |
emerge @system, but |
| 16 |
> |
| 17 |
> Would it be possible to do a "emerge -e @world" for the system |
| 18 |
> applications and then update the rest of the applications via the |
| 19 |
> regular updates of the system (and recompile failing components |
| 20 |
> manually because one obviously already know the reason) ? |
| 21 |
|
| 22 |
How do you know which packages are important? By doing a partial update |
| 23 |
you risk more problems and time wastage than just re-emerging @world in |
| 24 |
one go. |
| 25 |
|
| 26 |
> Do I have to do a "emerge -e @world" from a certain kind of |
| 27 |
> "reduced system" i.e. starting the system without a desktop |
| 28 |
> first or boot into an even more reduced state aka "maintance |
| 29 |
> mode" (via grub) and make the disk rw by hand? |
| 30 |
|
| 31 |
No, just do it. Add --keep-going to the emerge command and it will spit |
| 32 |
out a list of any failed packages at the end. Then you can deal with |
| 33 |
those as and when you see fit. In the time you have spent worrying about |
| 34 |
this, I have updated two systems, one after the other I wasn't brave |
| 35 |
enough to try in parallel, and dealt with the build failures. You are |
| 36 |
just creating more work for yourself. |
| 37 |
|
| 38 |
|
| 39 |
-- |
| 40 |
Neil Bothwick |
| 41 |
|
| 42 |
Sometimes too much to drink is not enough. |
Archives