Re: [gentoo-user] Re: libtool problem

[Dirk Heinrichs <dirk.heinrichs@online.de>]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]