| 1 |
First, stop top-posting, and fix your quoting. This is a mess to try |
| 2 |
to reply to, and your update woes are bad enough to stare at... |
| 3 |
|
| 4 |
On Wed, May 20, 2020 at 4:51 PM n952162 <n952162@×××.de> wrote: |
| 5 |
> |
| 6 |
> |
| 7 |
> Well, you're talking about openssl here. I'm trying to go a step at a time and looking at the first conflict in that first log file: zlib. |
| 8 |
|
| 9 |
You'll have to give me the full command line and output of that if you |
| 10 |
want me to comment. |
| 11 |
|
| 12 |
This seems to be a bit of a trend in your emails. You almost always |
| 13 |
ask a question without including the command line and output. When |
| 14 |
you do include output you often trim it, which makes it much harder to |
| 15 |
tell what is going on. |
| 16 |
|
| 17 |
|
| 18 |
> Isn't the source and build instructions to everything on my system here, too? |
| 19 |
> I mean, if it had to rebuild all the users of zlib, but wasn't being requested to update them. |
| 20 |
|
| 21 |
No. The build instructions are in the repository. When you updated |
| 22 |
it, you discarded the ebuilds for any no-longer-supported package |
| 23 |
versions. |
| 24 |
|
| 25 |
> |
| 26 |
> Something that might also help is running: |
| 27 |
> emerge -auDv --changed-use --keep-going --with-bdeps=y --changed-deps |
| 28 |
> --backtrack=100 @system |
| 29 |
> |
| 30 |
> |
| 31 |
> Attached ... |
| 32 |
> |
| 33 |
|
| 34 |
1. You should update all the files in /etc and then run that command again. |
| 35 |
2. Did portage not actually let you proceed with the update? As far |
| 36 |
as I can tell none of those errors are fatal. |
| 37 |
|
| 38 |
Assuming that nothing new comes up after you update all your config |
| 39 |
files in /etc I would proceed with this update. It certainly won't |
| 40 |
fix all your problems (which is why you have a mountain of messages |
| 41 |
after the list of packages that will be updated), but it will get a |
| 42 |
ton of system packages and your toolchain up-to-date, and will |
| 43 |
probably make it considerably easier to sort through the rest of the |
| 44 |
updates. |
| 45 |
|
| 46 |
The @system set is largely independent of anything else, so getting it |
| 47 |
updated makes everything else easier. |
| 48 |
|
| 49 |
|
| 50 |
> Actually, I installed this system just a month or two ago, but I used |
| 51 |
> a CD I burned of the minimal-install-disk that is perhaps a year |
| 52 |
> old. I wanted to have all my systems have the same basis, until I |
| 53 |
> proficient enough to do a stage-1 installation ... I guess this is the |
| 54 |
> way I'm learning how to get there :-( |
| 55 |
|
| 56 |
Two things: |
| 57 |
|
| 58 |
First, that seems a bit odd, since if you did an emerge --sync before |
| 59 |
doing the install you should have been installing new packages |
| 60 |
regardless of what was on the install disk, especially if you |
| 61 |
downloaded a current stage3. I guess if you used an old stage3 and |
| 62 |
didn't update anything then you'd be in that state, but you wouldn't |
| 63 |
have anything not in @system that way. |
| 64 |
|
| 65 |
Second, there is no benefit to doing a stage1 install really except in |
| 66 |
some unusual bootstrapping situations like building install media. |
| 67 |
You get an identical system if you do a stage1 install, or if you do a |
| 68 |
stage3 install and at the end do an emerge -e @world. The difference |
| 69 |
is that you can actually use your system while the latter rebuilds, vs |
| 70 |
a stage1 where it takes ages before you can just about anything with |
| 71 |
it. |
| 72 |
|
| 73 |
-- |
| 74 |
Rich |
Archives