1 |
On Wednesday 04 February 2009 22:40:26 Dirk Heinrichs wrote: |
2 |
> Am Mittwoch, 4. Februar 2009 21:21:38 schrieb Alan McKinnon: |
3 |
> > On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote: |
4 |
> > > Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD: |
5 |
> > > > The reason there wasn't a bump (IIRC) was that the ebuild never |
6 |
> > > > changed - only the eclass did. If you emerged any version of GCC |
7 |
> > > > during the window where the eclass was broken, that version of GCC |
8 |
> > > > would have been broken. |
9 |
> > > |
10 |
> > > That also means that portage is broken. Whenever something changes |
11 |
> > > where other things depend on, those other things should be rebuilt. |
12 |
> > > This doesn't happen here. |
13 |
> > |
14 |
> > I disagree, that would cause many more spurious rebuilds than is needed |
15 |
> > if it were automated. |
16 |
> |
17 |
> Why spurious? The package manager should be smart enough to tell the user: |
18 |
> "Rebuild because of eclass change". Nothing spurious. |
19 |
|
20 |
Portage only knows that the eclass changed. It does not know what the result |
21 |
of that change will be. Therefore it is not in a position to mandate that a |
22 |
rebuild of other apps is *required* in order to function correctly. Which |
23 |
leaves us with two options: |
24 |
|
25 |
Tell the user to look and decide for themselves, or |
26 |
Rebuild everything using the eclass anyway |
27 |
|
28 |
The latter option will always fix problems but at a huge cost of most often |
29 |
rebuilding something that looks like it needs rebuilding but actually |
30 |
doesn't. Therefore spurious. |
31 |
|
32 |
> > Portage cannot tell how important or how deep a change |
33 |
> > is, that requires a human to look and see. So what is needed is a flag |
34 |
> > that portage recognizes as an instruction to do a revdep-rebuild-style |
35 |
> > search and find everything using a specific changed file, and rebuild |
36 |
> > those. The flag is set under dev control. |
37 |
> |
38 |
> Not dev, user. Something equivalent to --newuse. |
39 |
|
40 |
I was thinking more along the lines of what @preserved-rebuild does. Some |
41 |
mechanism in the ebuild that includes a package in a list of stuff to be |
42 |
rebuilt. Obviously this is something new and a fairly deep change to portage |
43 |
so I can't think of a decent parallel or analogy. |
44 |
|
45 |
> > Blindly doing what you suggest leads to this: |
46 |
> > |
47 |
> > appA depends on libB. |
48 |
> |
49 |
> No. Sorry if this was misleading. I was only referring to dependencies |
50 |
> between ebuilds and eclasses. |
51 |
|
52 |
OK |
53 |
|
54 |
> Library interdependencies are handled just fine by portage/revdep-rebuild. |
55 |
> |
56 |
> > Therefore, a simple elog entry is a valid handling and fully compliant |
57 |
> > with the principle of The Simplest Thing That Could Possibly Work. |
58 |
> |
59 |
> Elog entries are overlooked too often. |
60 |
|
61 |
True, but do we have anything better? As in a proven mechanism successfully |
62 |
used elsewhere to deal with comparable situations? |
63 |
|
64 |
|
65 |
|
66 |
-- |
67 |
alan dot mckinnon at gmail dot com |