Re: [gentoo-user] How to degrade Gentoo system with webrsync method?

[gevisz]

вс, 9 янв. 2022 г. в 15:40, Dale <rdalek1967@×××××.com>:
>
> gevisz wrote:
> > вс, 9 янв. 2022 г. в 14:43, Dale <rdalek1967@×××××.com>:
> >> gevisz wrote:
> >>> вс, 9 янв. 2022 г. в 14:08, Arve Barsnes <arve.barsnes@×××××.com>:
> >>>> On Sun, 9 Jan 2022 at 12:48, gevisz <gevisz@×××××.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.