вс, 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.
