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 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.
> 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.
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.
Bye...
Dirk
signature.asc
Description: This is a digitally signed message part.
