1 |
Michael Orlitzky <mjo@g.o> wrote: |
2 |
> |
3 |
> Who generates the metadata when I `git pull`? |
4 |
|
5 |
For the gentoo repository, it is in general some gentoo server |
6 |
which then pushes the calculated metadata to the repository which |
7 |
you pull as a user. |
8 |
It is *possible* to use the "plain" repository, but you have to |
9 |
set up quite a bit for that (updating metadata is only one of |
10 |
several steps which you have to do manually in that case). |
11 |
|
12 |
A collection of scripts which do the missing steps is |
13 |
https://github.com/vaeth/portage-postsyncd-mv |
14 |
though I do not know whether they still work. Indeed (as |
15 |
probably most users) I am using since years one of the |
16 |
repositories with generated metadata already. |
17 |
|
18 |
> Or in overlays? |
19 |
|
20 |
There are overlays which provide metadata, and there are overlays |
21 |
where you have to do it on your own with egencache. Overlays which |
22 |
use eclasses from the gentoo repository usually do the latter, |
23 |
since otherwise the metadata is soon out-of-date. |
24 |
|
25 |
However, for most overlays, egencache takes far less than a minute, |
26 |
so for overlays, this is not really an issue. For the gentoo repository, |
27 |
the time of a full metadata generation is considerable. As mentioned, |
28 |
checksums and timestamps are used to minimize the amount, though this |
29 |
does not work for eclass changes (see below). |
30 |
|
31 |
> but if you record that wasted time in a different "metadata generation" |
32 |
> ledger, then it looks like I've saved a bunch of time because the "bash |
33 |
> sourcing" ledger reads zero. |
34 |
|
35 |
No. You need correct metadata after every syncing of the repository. |
36 |
Either the gentoo server or your machine has to do it. |
37 |
This is independent of whether the PM "prefers" the installed or |
38 |
the repositories' metadata. Excluding installed packages from metadata |
39 |
updating would not be sane and would not safe much time (since the vast |
40 |
majority of ebuilds are not installed, anyway). |
41 |
|
42 |
> Even if I believe in a metadata angel and if we pretend that the PMS |
43 |
> requires the metadata to be there, then rebuilding whenever metadata |
44 |
> changes is still not 100% correct (as you point out), because it often |
45 |
> rebuilds pointlessly. But that's getting into a harder problem. |
46 |
|
47 |
Yes, usually the metadata rebuilds due to eclass changes are pointless |
48 |
(except in the few cases where the eclass change is related with the |
49 |
metadata). |
50 |
|
51 |
I remember when I used to sync from the "plain" repository and rebuilt |
52 |
the metadata on my system, that the syncing (i.e. metadata regeneration) |
53 |
costed 10-30 minutes whenever one of the basic eclasses (which are |
54 |
sourced by almost every ebuild) had a trivial change. Probably, |
55 |
meanwhile machines are slightly faster and there are less such "basic" |
56 |
eclasses needed in newer EAPIs, but it will still need a considerable |
57 |
time. |
58 |
|
59 |
> The recompilation isn't always pointless. In the present scenario, the |
60 |
> rebuild is what installs the python-3.8 copy of the program. |
61 |
|
62 |
No. If users use the defaults for PYTHON_{,SINGLE}_TARGET, the |
63 |
rebuild has absolutely no effect except for changing some metadata |
64 |
in /var/db/pkg (and some file timestamps). |
65 |
|
66 |
> I'm not arguing that this is the best way to do things, but that it's |
67 |
> the only way to do them given what's in the PMS today. |
68 |
|
69 |
Of course. That was the decision made some years ago. |
70 |
|
71 |
> maybe it should pay a few people to sit around and think about |
72 |
> this for a week. |
73 |
|
74 |
There was such a debate some years ago, before the decision mentioned |
75 |
above was made. |
76 |
It was a hefty discussion, but there were strong proponents of pointless |
77 |
recompilation vs. improvement of the dependency handling (for both |
78 |
sides, there are much more arguments which I will not repeat now). |
79 |
The discussion might have turned if I would have found the time to |
80 |
implement the necessary change in portage, but neither then nor now |
81 |
I have the time to do so. (To be honest: Maybe I had the time, but I |
82 |
dislike python too much.) Nevertheless, I do not think that it was a |
83 |
good decision. |
84 |
I am not posting this to re-roll the above discussion again. |
85 |
But your posting shows that apparently not everybody knows the reasons |
86 |
why things are the way they are now. |