| 1 |
On Tue, Jun 18, 2019 at 12:07 PM Helmut Jarausch <jarausch@××××××.be> wrote: |
| 2 |
> |
| 3 |
> On 06/18/2019 05:43:55 PM, John Covici wrote: |
| 4 |
> > It would seem impossible for me to switch to profile 17.1. I say this |
| 5 |
> > because I can never run emerge --depclean . I have a few packages |
| 6 |
> > which will not compile and one not in the tree anymore. the packages |
| 7 |
> > which will not compile are mono-4.4.1.0 and totem-3.30 -- I have filed |
| 8 |
> > bugs against both of them. Inn no longer configures and I have |
| 9 |
> > discussed this in another thread. So, where can I go with this? I |
| 10 |
> > hate to just go forward, although these packages look they don't have |
| 11 |
> > any lib32 dependencies. Wat do you thihnk about this? |
| 12 |
> > |
| 13 |
> |
| 14 |
> I haven't run emerge --depclean. I have re-emerge gcc / glibc and all |
| 15 |
> packages with |
| 16 |
> files /usr/lib32 and /lib32 and some more which I don't remember. |
| 17 |
|
| 18 |
If you're unable to run --depclean (not necessarily if you just |
| 19 |
haven't run it recently), you could run into problems, sometime, |
| 20 |
probably not a convenient time. |
| 21 |
|
| 22 |
You don't HAVE to run it to do the migration, but I'd suggest |
| 23 |
generally cleaning things up first, because it makes it less likely |
| 24 |
that you'll run into issues, and it might reduce the time required to |
| 25 |
migrate. |
| 26 |
|
| 27 |
If you CAN'T run --depclean I'd definitely stop and fix whatever is |
| 28 |
wrong, otherwise you could run into issues during the migration, when |
| 29 |
they might be harder to resolve. |
| 30 |
|
| 31 |
> On the other hand I don't see such a big advantage of profile 17.1. |
| 32 |
> I have several (64 bit) packages (in my local portage tree) which still |
| 33 |
> install into /usr/lib |
| 34 |
> although this folder is now the replacement of the old /usr/lib32. |
| 35 |
|
| 36 |
The advantages are more around bringing Gentoo into better alignment |
| 37 |
with all the other distros and making packages more maintainable in |
| 38 |
the long-term. |
| 39 |
|
| 40 |
If packages are sticking 64-bit libraries in /usr/lib then I would |
| 41 |
file a bug, if there isn't already one open. There are known packages |
| 42 |
that don't work with 17.1. |
| 43 |
|
| 44 |
There isn't really a reason to rush into this, but long-term support |
| 45 |
for 17.0 will get dropped, so you will have to migrate, eventually. I |
| 46 |
would try to find a convenient time to do it. |
| 47 |
|
| 48 |
As far as --depclean issues go, it would be more helpful if we |
| 49 |
actually had details around the issues... |
| 50 |
|
| 51 |
-- |
| 52 |
Rich |
Archives