1 |
Michael Orlitzky <mjo@g.o> wrote: |
2 |
> What's happening is that the PM is using the metadata from the installed |
3 |
> version of the package, rather than the ninja-edited metadata in the |
4 |
> repo (how would it know which ebuilds were edited meaningfully?). |
5 |
|
6 |
The question is easy to answer: |
7 |
It is reasonable to assume that the repository metadata is correct |
8 |
and more up-to-date than the metadata of the installed version. |
9 |
But the PM would need to be smart enough to interpret subslot-deps |
10 |
correctly and merge that from the data of installed packages in a |
11 |
clever way. |
12 |
|
13 |
> That's completely legal according to the PMS, and also the |
14 |
> smart thing to do: |
15 |
|
16 |
s/smart/dumb/, but necessary for a dumb PM. |
17 |
|
18 |
> sourcing a few thousand lines of bash *just in case* there was an |
19 |
> important change in some ebuild is a huge waste of users' time. |
20 |
|
21 |
That's wrong: The metadata has to be (re)generated anyway, |
22 |
independent of whether this is a revision bump or just a modification. |
23 |
For most syncing methods the bash sourcing does not happen on the |
24 |
user's machine, and on those machines where the metadata is actually |
25 |
calculated, there are checksums and timestamps used to minimize the |
26 |
effort. From this perspective there is no difference between a |
27 |
modification or a revision bump. |
28 |
|
29 |
> Developers have an easy way to signal that there was an important |
30 |
> change: to bump the "r" number at the end of the ebuild. |
31 |
|
32 |
That's why it was decided to do it this way instead of requiring |
33 |
a smarter PM. Instead of putting some smart logic into the PM |
34 |
(which in case of portage was not fully implemented and in case |
35 |
of other package managers not at all), the decision was to force |
36 |
recompilations for every user and every tiny dependency change. |
37 |
|
38 |
> One developer makes a change, and it saves |
39 |
> thousands of users each a lot of time. |
40 |
|
41 |
... costs thousands of users a lot of compilation time, although |
42 |
the recompilation is completely pointless for each of them, but |
43 |
done only to keep the PM simpler. |