1 |
вс, 9 янв. 2022 г. в 14:43, Dale <rdalek1967@×××××.com>: |
2 |
> |
3 |
> gevisz wrote: |
4 |
> > вс, 9 янв. 2022 г. в 14:08, Arve Barsnes <arve.barsnes@×××××.com>: |
5 |
> >> On Sun, 9 Jan 2022 at 12:48, gevisz <gevisz@×××××.com> wrote: |
6 |
> >>> The problem is that I do not know how to sync my Gentoo repository |
7 |
> >>> to the state it was on 12-12-2021. |
8 |
> >>> |
9 |
> >>> I use webrsync sync method via "emaint -A sync" and would prefer |
10 |
> >>> to use the same sync method for degrading my Gentoo system. |
11 |
> >>> |
12 |
> >>> Can anybody, please, tell me how to do it using this sync method? |
13 |
> >> This is probably not possible at all using any of the tools available. |
14 |
> >> These tools only support downloading the latest snapshot to get you up |
15 |
> >> to date. Additionally, most mirrors only keep snapshots of the last 7 |
16 |
> >> days or so, so it would take some (possibly futile) effort to find a |
17 |
> >> snapshot of the date you need. |
18 |
> >> |
19 |
> >> The only option, as far as I can see, is to migrate your portage tree |
20 |
> >> to git, where you can specify a commit that you want to sync to from |
21 |
> >> the wanted day. |
22 |
> > It is a pity, but thank you for the answer. |
23 |
> |
24 |
> I'm not sure if I'm understanding completely the problem here but |
25 |
> thought I'd suggest something. Can you not just mask newer versions of |
26 |
> the package so emerge won't update it until you are ready? I do that |
27 |
> sometimes here. I've did it with smplayer at one point because some |
28 |
> changes broke things for me. I kept it from upgrading for months until |
29 |
> things got fixed. I then removed the mask, while keeping the old ebuild |
30 |
> and even a binary of the package, and allowed emerge to upgrade |
31 |
> smplayer. At that point, things worked for me that didn't before. |
32 |
> |
33 |
> The only downside to this, things your package depends on may go past |
34 |
> what your package supports and you run into issues. As the other person |
35 |
> said, it's best to figure out why your package fails and fix that, then |
36 |
> you can worry about new problems. ;-) Masking the newer version may |
37 |
> work at least in the meantime though. Give you time to sort out the failure. |
38 |
|
39 |
Thank you for your reply, Dale. |
40 |
|
41 |
Yes, masking some new package can work in this case. |
42 |
|
43 |
However, it is not so easy as it may seem because it is not the new |
44 |
version of tensorflow that I should mask in my case as on the day |
45 |
when the tensorflow recompilation failed its version remained the same |
46 |
and only some of its dependencies were supposed to be upgraded. |
47 |
|
48 |
Of course, I may try this approach. However, tensorflow is not |
49 |
considered stable in gentoo tree and it has a lot of dependencies |
50 |
that are also not considered stable and should be unmasked. |
51 |
|
52 |
All this leads to a large number of possible choices on |
53 |
which packages to mask/unmask. |
54 |
|
55 |
So, playing with this is like playing in a casino with about |
56 |
4 hours of compilation for each bet. |