| 1 |
On 5/2/16 6:31 PM, Ian Stakenvicius wrote: |
| 2 |
> Quote: blueness: |
| 3 |
>> |
| 4 |
>> The big problem is going to be the migration. You can't just unmerge |
| 5 |
>> uclibc and emerge uclibc-ng. The two hard block one another for that |
| 6 |
>> reason. The migration path I took is really really dirty but works: |
| 7 |
>> |
| 8 |
>> 1. ebuild uclibc-ng-<version>.ebuild clean install |
| 9 |
>> 3. Copy .so files from /var/tmp/portage/.../image/lib to /lib |
| 10 |
>> Since the .so versions are different they won't overwrite. |
| 11 |
>> 4. Use a static binary to switch over the sym links to the new .so's |
| 12 |
>> 5. emerge uclibc-ng properly |
| 13 |
>> 6. re-emerge world |
| 14 |
>> |
| 15 |
>> I can automate some of that with scripts, but it will take care on the |
| 16 |
>> part of the user who should be ready to boot off of rescue media. I'm |
| 17 |
>> going to recommend that people really avoid that if possible and start anew. |
| 18 |
>> |
| 19 |
> |
| 20 |
> What about a "unclibc-ng-migrator" ebuild that would do steps 1,3,4 above if uclibc-ng isn't installed yet, and be a no-op otherwise? This could be a dep of uclibc-ng, and not hard-block uclibc. A bit hackish but emerge would probably enforce the order of things ok with deptree resolution. |
| 21 |
> |
| 22 |
|
| 23 |
yeah, i can see that working, but let me get uclibc-ng going first. |
| 24 |
|
| 25 |
-- |
| 26 |
Anthony G. Basile, Ph.D. |
| 27 |
Gentoo Linux Developer [Hardened] |
| 28 |
E-Mail : blueness@g.o |
| 29 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 30 |
GnuPG ID : F52D4BBA |
Archives