On Tue, 11 Jun 2019 at 12:34, Helmut Jarausch <jarau...@skynet.be> wrote:
> I had some trouble switching to the new profile 17.1.
> Following the advice in the news item didn't suffice.
>
> I had to reinstall some packages "by hand", e.g.
> I had to reinstall util-linux quite early.
> I had to reinstall x11-libs/libva without the opengl USE flag, since it
> couldn't find libopenGL otherwise.
>
> After reinstalling mesa (which depends on libva), I'll try to reinstall
> x11-libs/libva with the opengl USE flag.
>
> Currently I'm reemerging gcc bintuils glibc before I proceed with the
> other packages selected by
> emerge -v1 /usr/lib/gcc /lib32 /usr/lib32
>
> Perhaps, it's only me.
>
> It isn't. It took me a few days to switch up to 17.1/plasma (because of
pesky things like sleep and work).
first off, `emerge -v1 /lib /lib32` didn't work out because I had an old
library in there I
had to remove with `emerge --depclean` first. I also have an old install of
sickbeard, which
I had to remove from world for the same reason: `emerge -v1 /lib /lib32`
would just complain
about not being able to find an installable source (my words -- can't
remember the original
terms), but it didn't really look like an error -- all green text.
I thought I'd just hitch on to the recommended line after that in the news
item: `emerge -ev @world`,
which would periodically break, usually in the configure stage. I didn't
know this before, but it seems
that `emerge -e @world` does not merge in dependency order. (Is there a way
to make it do so?)
I started with hunting down and applying `emerge -1` with deps which didn't
work, eg:
`eix {whatever the last thing complained about}`
(look for package which is already installed, and "seems right")
`emerge -1 {whatever I found}`
However, it seems that a bigger hammer may have just worked as well, as I
resorted to this after about 20
or so hand-helped packages:
`emerge -ev @world --keep-going`
followed by
`emerge --resume`
as many times as were necessary until there were no errors in the output.
I also had to manually remove a symlink for libidns.so.11, which was in
/usr/lib64, but pointing at /usr/lib
(so ld was complaining after every install) and I had to manually remove
/lib32, after doing `equery b /lib32`
and all the results mentioning `(lib)` in the line, so I _assumed_ that
meant that equery was dereferencing
/lib32.
On that note, does anyone know of a way to figure out what atom a symlink
belongs to? Not what it points at
-- `equery b /usr/lib64/libidn.so.11` told me that it belonged to libidns,
probably because it was dereferencing
to /usr/lib/libidn.so, which eventually dereferences to
/usr/lib/libidn.so.12.6.0, which _does_ belong to libidn,
but what finally gave me the confidence to delete it was to spelunk through
the output of `emerge -1 libidn`
and see that there was no `.11.so` symlink, so I deleted it, and, out of
paranoia, rebuilt -- and it didn't re-appear.
It would have been great to have been able to run `equery b
/usr/lib64/libidn.so.11` and get back nothing, to know
"for sure" that it's an invalid link, and I assume there's a way to do so
that I'm just not aware of?
-d
Helmut
>
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing
Which is stupid.
- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY
*Quidquid latine dictum sit, altum sonatur. *
