Fw: Re: Re: [gentoo-user] .tmp-unverified-download-quarantine

In what way is emerge sensitive to reduced bandwidth?

> Gesendet: Donnerstag, 16. Januar 2020 um 11:48 Uhr
> Von: "Peter Humphrey" <peter@××××××××××××.uk>
> An: n952162 <n952162@×××.de>
> Betreff: Re: Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine
>
> On Thursday, 16 January 2020 07:28:19 GMT you wrote:
>
> > But it's not synced, and that's the point in the end.
>
> Well, it isn't far off. The tarball will have been made no earlier than the
> previous day.
>
> > Now I don't know, if I run emerge --sync, will it corrupt the system
> > I've just installed?
>
> I can't see how. The worst it can do is to repeat your original problem, and
> you'll be no worse off except for the disk space used. If the --sync fails on
> verification, the new portage tree will be left in quarantine; that's what the
> verification step is for.
>
> I've reinstalled systems here recently more often than I can count, and I've
> always gone on from emerge-webrsync without another --sync. When I have a
> bootable system I do boot it, then finish the system build natively, as it
> were.
>
> When all packages have been installed and configured, I do a --sync and an -e
> @world, just to make sure everything fits together properly*.
>
> You will need to do something about that DSL link though, if it's still as bad
> while running your new system.
>
> * Actually, I'm more paranoid than that: I do an emerge @system, then
> recompile and reboot the kernel, then an -e @world minus what was installed by
> @system. I've no doubt that all the experts would say it's pointless, but I
> learned caution when I was leading the team that maintained the 15-mainframe
> system at five control centres that runs the national grid in England and
> Wales. That was 25 years ago, but some habits stick - and CPU cycles are
> cheap.
>
> --
> Regards,
> Peter.
>
>
>
>