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