вс, 9 янв. 2022 г. в 15:40, Dale <rdalek1...@gmail.com>: > > gevisz wrote: > > вс, 9 янв. 2022 г. в 14:43, Dale <rdalek1...@gmail.com>: > >> gevisz wrote: > >>> вс, 9 янв. 2022 г. в 14:08, Arve Barsnes <arve.bars...@gmail.com>: > >>>> On Sun, 9 Jan 2022 at 12:48, gevisz <gev...@gmail.com> wrote: > >>>>> The problem is that I do not know how to sync my Gentoo repository > >>>>> to the state it was on 12-12-2021. > >>>>> > >>>>> I use webrsync sync method via "emaint -A sync" and would prefer > >>>>> to use the same sync method for degrading my Gentoo system. > >>>>> > >>>>> Can anybody, please, tell me how to do it using this sync method? > >>>> This is probably not possible at all using any of the tools available. > >>>> These tools only support downloading the latest snapshot to get you up > >>>> to date. Additionally, most mirrors only keep snapshots of the last 7 > >>>> days or so, so it would take some (possibly futile) effort to find a > >>>> snapshot of the date you need. > >>>> > >>>> The only option, as far as I can see, is to migrate your portage tree > >>>> to git, where you can specify a commit that you want to sync to from > >>>> the wanted day. > >>> It is a pity, but thank you for the answer. > >> I'm not sure if I'm understanding completely the problem here but > >> thought I'd suggest something. Can you not just mask newer versions of > >> the package so emerge won't update it until you are ready? I do that > >> sometimes here. I've did it with smplayer at one point because some > >> changes broke things for me. I kept it from upgrading for months until > >> things got fixed. I then removed the mask, while keeping the old ebuild > >> and even a binary of the package, and allowed emerge to upgrade > >> smplayer. At that point, things worked for me that didn't before. > >> > >> The only downside to this, things your package depends on may go past > >> what your package supports and you run into issues. As the other person > >> said, it's best to figure out why your package fails and fix that, then > >> you can worry about new problems. ;-) Masking the newer version may > >> work at least in the meantime though. Give you time to sort out the > >> failure. > > Thank you for your reply, Dale. > > > > Yes, masking some new package can work in this case. > > > > However, it is not so easy as it may seem because it is not the new > > version of tensorflow that I should mask in my case as on the day > > when the tensorflow recompilation failed its version remained the same > > and only some of its dependencies were supposed to be upgraded. > > > > Of course, I may try this approach. However, tensorflow is not > > considered stable in gentoo tree and it has a lot of dependencies > > that are also not considered stable and should be unmasked. > > > > All this leads to a large number of possible choices on > > which packages to mask/unmask. > > > > So, playing with this is like playing in a casino with about > > 4 hours of compilation for each bet. > > As a starting point, check the ebuild and see what all packages are > listed there that it depends on. Put the needed entries in package.mask > and then use your world upgrade command plus -p to see what emerge wants > to upgrade. Keep adding until it is reporting nothing to upgrade. The > packages in the ebuild should help save some time. I can't think of an > easier way to do it. Someone else may have ideas thogh. Oh, don't forget > the ">=" signs and to specify versions. Can't recall if it matters > which symbol comes first.
Thank you. I probably should also look into the emerge logs to see which of the tensorflow dependencies was updated the last time, when its recompilation failed.
