| 1 |
Quote: blueness: |
| 2 |
> |
| 3 |
> The big problem is going to be the migration. You can't just unmerge |
| 4 |
> uclibc and emerge uclibc-ng. The two hard block one another for that |
| 5 |
> reason. The migration path I took is really really dirty but works: |
| 6 |
> |
| 7 |
> 1. ebuild uclibc-ng-<version>.ebuild clean install |
| 8 |
> 3. Copy .so files from /var/tmp/portage/.../image/lib to /lib |
| 9 |
> Since the .so versions are different they won't overwrite. |
| 10 |
> 4. Use a static binary to switch over the sym links to the new .so's |
| 11 |
> 5. emerge uclibc-ng properly |
| 12 |
> 6. re-emerge world |
| 13 |
> |
| 14 |
> I can automate some of that with scripts, but it will take care on the |
| 15 |
> part of the user who should be ready to boot off of rescue media. I'm |
| 16 |
> going to recommend that people really avoid that if possible and start anew. |
| 17 |
> |
| 18 |
|
| 19 |
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. |
Archives